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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 of the LoCation Services (LCS) feature in GERAN, which provides the 
mechanisms to support mobile location services for operators, subscribers and third party service providers. 

The purpose of this stage 2 specification is to define the GERAN LCS architecture, functional entities and operations to 
support location methods. This description is confined to the aspects of LCS within the GERAN and does not define nor 
describe the LCS entities or operations within the Core Network. 

Location Services may be considered as a network provided enabling technology consisting of standardised service 
capabilities, which enable the provision of location applications. The application(s) maybe service provider specific. 
The description of the numerous and varied possible location applications which are enabled by this technology are 
outside the scope of the present document. However, clarifying examples of how the functionality being described may 
be used to provide specific location services may be included. 

This stage 2 specification covers the GERAN LCS functional model and entities, the location methods, state 
descriptions, and message flows. 
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Definitions and abbreviations 



3.1 Definitions 



For the purposes of the present document the following terms and definitions apply and the terms and definitions given 
in 3GPPTS 22.101. 

A/Gb mode: see 3GPP TS 43.051 [11]. 

lu mode: see 3GPP TS 43.051 [11]. 

LCS (Location Services): LCS is a service concept in system standardisation. LCS specifies all the necessary network 
elements and entities, their functionality, interfaces, as well as communication messages, necessary to implement the 
positioning functionality in a cellular network. 

NOTE 1 : LCS does not specify any location based (value added) services except locating of emergency calls. 

LCS Client: software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location 
information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information. 
LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting 
data and managing the user interface (dialogue). The LCS Client may reside in the Mobile Station (MS). 

LCS Server: software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services 
requests, and sends back responses to the received requests. The LCS server consists of LCS components, which are 
distributed to one or more PLMN and/or service provider. 

Location Estimate: geographic location of an MS and/or valid Mobile Equipment (ME), expressed in latitude and 
longitude data. The Location Estimate shall be represented in a well-defined universal format. Translation from this 
universal format to another geographic location system may be supported, although the details are considered outside 
the scope of the primitive services. 

Location Request: request for a Location Estimate and optionally a Velocity Estimate. 

Mobile Assisted positioning: any mobile centric positioning method (e.g. E-OTD, A-GNSS) in which the MS provides 
position measurements to the network for computation of a location estimate by the network. The network may provide 
assistance data to the MS to enable position measurements and/or improve measurement performance. 

Mobile Based positioning: any mobile centric positioning method (e.g. E-OTD, A-GNSS) in which the MS performs 
both position measurements and computation of a location estimate and where assistance data useful or essential to one 
or both of these functions is provided to the MS by the network. Position methods where an MS performs 
measurements and location computation without network assistance data are not considered within this category. 

Mobile Station: consists of Mobile or User Equipment (ME or MS) with a valid SIM or USIM attached. 

Positioning (/location detecting): positioning is a functionality, which detects a geographical location (of e.g. a mobile 
terminal). 

Positioning technology (/locating technology): technology or system concept including the specifications of RF 
interfaces, data types, etc. to process the estimation of a geographical location, e.g. A-GNSS and E-OTD. 

Radio Interface Timing: Comprise Absolute Time Differences (ATDs) or Real Time Differences (RTDs) of the 
signals transmitted by Base Stations, where timing differences are measured relative to either some absolute time 
difference (ATD) or the signals of another Base Station (RTD). 

RRLP maximum PDU size: maximum PDU size for the RRLP protocol, which is 242 octets. 

RRLP pseudo-segmentation: use of several RRLP data messages to deliver a large amount of information. 

Target MS: Mobile Station being positioned. 

Type A LMU: accessed exclusively over the air interface (Um interface): there is no wired connection to any other 
network element. 
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Type B LMU: is accessed over the Abis interface from a BSC. The LMU may be either a standalone network element 
addressed using some pseudo-cell ID or connected to or integrated in a BTS. 

Velocity Estimate: speed and bearing of an MS and/or valid Mobile Equipment (ME), expressed as speed in kilometres 
per hour and bearing in degrees measured clockwise from North. 

NOTE 2: Abis interface is beyond the scope of the present document. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations and the abbreviations given in 3GPP TS 21.905 
apply. 

2G- Second Generation 

3G- Third Generation 

A Interface between GERAN BSS and MSC 

A-GNSS Assisted GNSS 

A-GPS Assisted GPS 

ATD Absolute Time Difference 

BSSLAP Base Station System Application Part 

BSSAP-LE Base Station System Application Part LCS Extension 

CBC-BSC Interface between CBC and BSC 

CBC-SMLC Interface between CBC and SMLC 

D-GPS Differential GPS 

E-OTD Enhanced Observed Time Difference 

GNSS Global Navigation SatelUte System (e.g. GPS, Gahleo) 

lu Interface between GERAN BSS and 3G Core Network 

lu-cs Interface between GERAN BSS and 3G MSC 

lu-ps Interface between GERAN BSS and 3G SGSN 

Gb Interface between GERAN BSS and SGSN 

Lb Interface between SMLC and BSC 

LCCF Location Client Control Function 

LCF Location Client Function 

LSBcF Location System Broadcast Function 

LSCF Location System Control Function 

LSOF Location System Operation Function 

PCF Position Calculation Function 

PRCF Positioning Radio Co-ordination Function 

PRRM Positioning Radio Resource Management 

PSMF Positioning Signal Measurement Function 

RIT Radio Interface Timing 

RRLP Radio Resource Link Protocol 

RTD Real Time Difference 

SMSCB Short Message Service Cell Broadcast 

SMLCPP Serving Mobile Location Center Peer Protocol 

TA Timing Advance 

UDT SCCP Unitdata message 

Um GERAN Air Interface 

UTC Universal Coordinated Time 

U-TDOA Uplink Time Difference of Arrival 



IVIain concepts 



A general description of location services and the service requirements is given in the specification 3GPP TS 22.07 L 
By measuring radio signals the capability to determine the geographic location of the mobile station (MS) shall be 
provided. The location information may be requested by and reported to a client (application) associated with the MS, 
or by a client within or attached to the Core Network. The location information may also be utilised internally by 
GERAN, for example to support features such as home location billing. The location information shall be reported in 
standard formats, such as those for cell based or geographical coordinates of the location of the MS. 
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It shall be possible for the majority of the MS (active or idle) within a network to use the feature without compromising 
the radio transmission or signalling capabilities of the GERAN. 

Four positioning mechanisms are supported for LCS: Timing Advance (TA), Enhanced Observed Time Difference 
(E-OTD), Global Navigation Satellite System (GNSS) based positioning (A-GNSS) and UpUnk Time Difference Of 
Arrival (U-TDOA). 

4.1 Assumptions 

SMLC is either an integrated functionality in BSS or a standalone network element within GERAN. 

LMU is either an integrated functionality in BTS (Type B LMU) or a standalone network element (Type A 
LMU) where communication is over the Um interface. 

4.2 Standard LCS Methods 

4.2.1 Timing Advance 

The TA is based on the existing Timing Advance (TA) parameter. The TA value is known for the serving BTS. To 
obtain TA values in case the MS is in idle mode a special procedure, not noticed by the GSM subscriber (no ringing 
tone), is set up. The cell-ID of the serving cell and the TA is returned as the result of the TA. 

TA may be used to assist all positioning mechanisms. 

4.2.2 Eninanced Observed Time Difference (E-OTD) positioning 
meciianism 

The E-OTD method is based on measurements in the MS of the Enhanced Observed Time Difference of arrival of 
bursts of nearby pairs of BTSs. For E-OTD measurement synchronization, normal and dummy bursts are used. When 
the transmission frames of BTSs are not synchronized, the network needs to measure the Real or Absolute Time 
Differences (RTDs or ATDs) between them. To obtain accurate trilateration, E-OTD measurements and, for 
non-synchronized BTSs, RTD or ATD measurements are needed for at least three distinct pairs of geographically 
dispersed BTSs. Based on the measured E-OTD values the location of MS can be calculated either in the network or in 
the MS itself, if all the needed information is available in MS. 

4.2.3 Global Navigation Satellite System (GNSS) based positioning 
mechanism 

Global Navigation Satellite System (GNSS) refers to satellite systems that are set up for positioning purposes. Systems 
belonging to this category, that are operational today or will be in the near future are e.g., GPS, Galileo, Satellite Based 
Augmentation Systems (SBAS), Modernized GPS, Quasi Zenith Satellite System (QZSS) and GLONASS. 

A mobile station with GNSS measurement capability may operate in an autonomous mode or in an assisted mode for 
example MS-assisted or MS-based mode. In autonomous mode MS determines its position based on signals received 
from GNSS without assistance from network. In assisted mode, MS receives assistance data from network. MS may 
support one or several GNSSs and the assistance data content may vary depending on this capability. 

A-GNSS refers to a concept which supports several global navigation satellite systems and their different navigation 
signals, including e.g. GPS, Galileo, Satellite Based Augmentation Systems (SBAS), Modernized GPS, Quasi Zenith 
Satellite System (QZSS) and GLONASS. The assistance data shall enable combined usage of satellite signals belonging 
to different GNSS or simple usage of one GNSS system independently from the other. 

4.2.4 Uplink Time Difference of Arrival (U-TDOA) positioning mechanism 

The U-TDOA positioning method is based on network measurements of the Time Of Arrival (TO A) of a known signal 
sent from the mobile and received at three or more LMUs. The known signal is the normal bursts generated by a mobile 
while in the dedicated mode; either on the SDCCH or TCH. The method requires LMUs in the geographic vicinity of 
the mobile to be positioned to accurately measure the TOA of the bursts. Since the geographical coordinates of the 
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measurement units are known, the mobile position can be calculated via hyperbolic trilateration. This method will work 
with existing mobiles without any modification. 



GERAN LCS Architecture 



Figure 1 shows the general arrangement of the Location Service feature. This illustrates, generally, the relation of LCS 
Clients and servers in the core network with the GERAN. The definition and operation of LCS entities operating in the 
core network is outside the scope of the present document. The LCS entities within the GERAN communicate with the 
Core Network (CN) across the A, Gb and lu interfaces. 

Communication among the GERAN LCS entities makes use of the messaging and signalling capabilities of the 
GERAN. 

As part of their service or operation, the LCS Clients may request the location information of Mobile Station. There 
may be more than one LCS client. These may be associated with the core network, associated with the GERAN, 
operated as part of a MS application or accessed by the MS through its access to an application (e.g. through the 
Internet). 

Within the GERAN, the BSC receives authenticated requests for LCS information from the core network across the A, 
Gb or lu interface and passes these to the SMLC. The SMLC may be a standalone network element or functionality that 
is integrated to the BSC. LCS entities then manage the GERAN resources, including the base station, the LMU, the MS 
and calculation functions, to estimate the location of the MS and return the result to the Core Network. 



MS 



Urn 



BSS 



lur-g 




BSS 




BSC 


: SMLC: \ CBC 





GERAN 



Lb 



SMLC 



CBC-BSC 



CBC 



CBC-SMLC 



Gb 



GSM/UMTS 
Core Network 



Figure 1 : Functional LCS Architecture in GERAN 
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5.1 LCS Operations 



The schematic functional description of LCS operations is defined in figure 2. 

Upon request from the LCS entities or for internal operations, the GERAN LCS functional entities will: 

request measurements, typically from the MS and/or one or more BTS radio apparatus; 

send the measurement results to the appropriate calculating function within GERAN; 

receive the result from the calculating function within GERAN; 

send the results to the LCS entities in the core network or to application entities within GERAN. 

In the event that the client is internal to GERAN the request may be made directly to the GERAN LCS entities as the 
internal clients are considered to be "pre-authorised". 

As part of its operation, the GERAN LCS calculating function may require additional information. This may be 
obtained by the function directly by communication with a database, or it may be through a request to GERAN LCS 
entities that will mediate the request and return of information from the appropriate database (or databases if more than 
one is needed to fulfil the requests). 

There may possibly also be available independent information that is able to supply the location information directly, or 
may be able to supply auxiliary information to the calculation function. The GERAN LCS co-ordination function, as 
part of its activity to supervise the location process, may query the MS or other elements of the GERAN to determine 
their capabilities and use this information to select the mode of operation. 

This general operation is outlined in the following (generic) sequence diagram Figure 2. This figure is not intended to 
show the complete LCS operation for GERAN, but to simply to outline the basis for operation. Location measurements 
may continually be taken in the background. 
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Figure 2: General sequence for LCS operation 
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5.2 High-Level Functions 



Several functional groupings may be defined to describe the LCS. These groupings occur in both the Core Network and 
the GERAN. The overall LCS functional grouping is described in the system stage 2, 3GPP TS 23.271. Each grouping 
encompasses a number of functional components and functions. 

The functions within the GERAN are described in more detail in the following clauses of the present document. 

Within GERAN the functional entities may be grouped as follows: 

the Internal Client group; 

the GERAN System Handling group; 

the Positioning group. 

The LCS functional diagram shown in figure 3 depicts the interaction of the LCS functional entities within the GERAN. 
The GERAN uses the various LCS components to provide the target MS Location Information to the internal LCS 
client. 
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Figure 3: GERAN LCS Capability Functional Diagram 

5.2.1 Co-ordination, Measurement and Calculation Functions 

These GERAN functions (including functions in the System handling and Positioning groups) provide the 
co-ordination, measurement and calculation functions needed to provide a location estimate. The functions interface 
with the requesting application and select the appropriate location method and speed of response. The functions 
co-ordinate the operations of the radio and measurement equipment to transmit the needed signals and to make the 
needed measurements. The functions may also access databases or other sources of information appropriate for the 
location method. The functions also provide the calculation functions appropriate for the location method to estimate 
the MS location and the accuracy of the report. The functions also may record information on the usage of the LCS that 
may be used for administrative purposes (e.g. forwarded to a billing function in the Core Network). If needed by the 
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location method, the functions will ensure the broadcast of information and gather and update information concerning 
GERAN operating parameters (e.g. timing of BTS transmissions) needed for LCS operations. 

These entities are mainly concerned with the location method, controlling the radio equipment and performing the 
calculations to determine the location and thus may be associated with the SMLC in the GERAN. These functions may 
receive location requests from either the core network or from applications internal to the GERAN. 

These functions communicate with the core network across the A, Gb and lu interfaces, and with the BTS and LMU 
and with the MS across the Um interface. 

5.3 GERAN LCS Functional Entities 

5.3.1 Internal Client Group 

5.3.1 .1 Internal GERAN Location Client Function (LCF) 

The Location Client Function (LCF) represents a logical interface between the internal GERAN LCS applications and 
the LCS BSC Handling entities (e.g. the Location System Control Function (LSCF) in the BSC). 

NOTE: There is not necessarily a requirement for a LCCF (Location Client Control Function) for the GERAN 
Internal Client as is described for external clients in the system stage 2 specification, 3GPP TS 23.27 L 

The GERAN may make use of location information for internal operations such as location assisted handover. In such a 
case, a LCF representing the internal GERAN LCS application may communicate with the LSCF to request and receive 
the location information. 

5.3.2 GERAN System Handling group 

5.3.2.1 GERAN Location System Control Function (LSCF) 

The GERAN Location System Control Function is responsible for co-ordinating location requests. This function 
manages call-related and non-call-related location requests and allocates network resources for handling them. This 
function "insulates" the Location clients in the Core Network from the detailed operation of the location method in 
order that the GERAN may be used by several types of core network and with several location methods. 

The LSCF provides flow control between simultaneous location requests. Simultaneous location requests must be 
queued in a controlled manner to account for priority requests (e.g. for Emergency Clients). The details of the flow 
control, priority selection and queuing are beyond the scope of the present document. 

The LSCF will select the appropriate location method based on the availability of resources and parameters of the 
location request. The LSCF coordinates resources and activities needed to obtain data (e.g. base station geographic 
coordinates) needed for the location method. It also records LCS usage data for the location service request that may be 
passed to a Location System Recording Function (LSRF) or O&M function in the Core Network. 

5.3.2.2 GERAN Location System Operations Function (LSOF) 

The Location System Operations Function (LSOF) is responsible for provisioning of data, location capabilities, data 
related to clients and subscription (LCS client data and MS data), fault management and performance management of 
LCS within the BSC. 

An LSOF may be associated with each entity. The LSOF interacts with Internal (O&M) Clients for administration and 
maintenance of the data. 

5.3.2.3 Location System Broadcast Function (LSBcF) 

The Location System Broadcast Function (LSBcF) provides broadcast capability. The LSBcF capability is only used 
when broadcast data is required for E-OTD or A-GNSS positioning methods. Broadcast information (such as the 
geographic coordinates of the base stations) may be required, for example, to support a Position Calculation Function 
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(PCF) located in the mobile station. These broadcasts may also include other information (such as currently observable 
satellites) that may assist a MS in the use of external location services. 

The information to be broadcast is selected based on the location techniques offered for use by the LCS and the needs of 
the MS. This broadcast information may be specially coded (i.e. encrypted) to ensure its availability only to subscribers 
of the service. The use of broadcasts or other methods for signalling to the MS may be selected based on the chosen 
location method. 

The information to be broadcast includes for example: 

1, E-OTD Assistance: 

Reference Time; 

Neighbour Channel Time Slot Scheme; 

Information about sectored neighbour channels; 

Neighbour channel 5 1 Multiframe Offset values; 

Neighbour channel BCC values; 

RTD Drift Factor values (ciphered if active); 

Neighbour channel RTD values (ciphered if active); 

Serving cell and neighbour cell location information (ciphered if active). 

2. A-GNSS Assistance Data: 

Broadcasted assistance data may be the same as in A-GNSS point-to-point signalling. 

5.3.3 Positioning group 

5.3.3.1 GERAN Position Radio Co-ordination Function (PRCF) 

The GERAN Position Radio Control Function manages a location request for a MS through overall co-ordination and 
scheduling of resources to perform location measurements. This function interfaces with the PSMF, the PRRM and the 
PCF. The PRCF determines the location method to be used based on the location request, the QoS, the capabilities of 
the GERAN, and the MS's capabilities. The PRCF also manages the needed radio resources through the PRRM. It 
determines which PSMFs are to be involved, what to measure, and obtains processed signal measurements from the 
PSMF. 

Some location methods may involve measurements made at the MS. In this case the PRCF interfaces with the MS to 
obtain the measurements (or the location results if they have been determined by the MS). Some location methods may 
involve measurements or information from several sources, including radio units at several BTSs and involve a series of 
transmissions and receptions. The PRCF entity also provides ancillary measurements in case of network-assisted 
location method. Ancillary information may be extracted from navigating systems like GNSS. 

The PRCF forwards the signal measurement data to the PCF. 

It is the function of the PRCF to co-ordinate the sequence of activities and compensate for failures (if they occur) to 
provide the location estimate. 

5.3.3.2 GERAN Position Calculation Function (PCF) 

The GERAN Position Calculation Function is responsible for calculating the location of the MS. This function applies 
an algorithmic computation on the collected signal measurements to compute the final location estimate and accuracy. 

The PCF would also be responsible for calculating the speed and bearing of the MS when reported. This function 
applies an algorithmic computation on the collected signal measurements to compute the final velocity estimate and 
uncertainty. 
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It may obtain related data (e.g.: base station geographic coordinates) needed for the calculation. There may be more 
than one calculating function available within, or associated with, the calculation function of the GERAN. 

The Position Calculation Function is also responsible for estimating the accuracy of the location estimate. 



5.3.3.3 



GERAN Position Signal Measurement Function (PSIVIF) 



The GERAN Position Signal Measurement Function (PSMF) is responsible for performing and gathering uplink or 
downlink radio signal measurements for use in the calculation of a MS's location and velocity. These measurements can 
be location related or ancillary. 

There may be one or more PSMF within a GERAN and they may be located at the MS or a Location Measurement Unit 
(LMU). The PSMF, generally, may provide measurement of signals (i.e. satellite signals) in addition to measurements 
of the GERAN radio transmissions. The measurements to be made will depend on the selected location method. 



5.3.3.4 



GERAN Position Radio Resource IVIanagement (PRRIVI) 



The GERAN Position Radio Resource Management entity is responsible for managing the effect of LCS operations on 
the overall performance of the radio network. This may ensure, for example, that the operation of the PSMF does not 
degrade the QoS of other calls. 

5.4 Assignment of LCS Functional Entities to GERAN Elements 

The following Table 1 shows the generic configuration for different location methods, including network-based, 
mobile-based, mobile-assisted and network-assisted methods. With this approach both the network and the mobiles are 
able to measure the timing of signals and compute the mobile's location and velocity estimate. Depending on the 
applied location method it is possible to utilise the corresponding configuration containing all needed entities. For 
instance, if a network-based location method is applied, the entities that are involved in measuring the mobile's signal 
and calculating its location estimate are allocated to the network elements of the access network. On the other hand, in 
case mobile-based or network-assisted methods are used these entities should be allocated to the mobile station. 

Table 1 : Example Allocation of LCS Functional Entities to Network Elements 
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5.5 Functional Description of GERAN LCS Network Elements 



5.5.1 



BSC 



The BSC receives authenticated requests for LCS information from the CN across A, Gb and lu interfaces and passes 
these to the SMLC. 

5.5.2 SMLC 

The SMLC is either a separate network element of GERAN or integrated functionality in BSC that contains 
functionality required to support LCS. The SMLC manages the overall co-ordination and scheduling of resources 
required for the location of a mobile. It also calculates the final location and velocity estimate and estimates the 
achieved accuracy. The SMLC may control a number of LMUs for the purpose of obtaining radio interface 
measurements to locate or help locate MS subscribers in the area that it serves. The SMLC is administered with the 
capabilities and types of measurement produced by each of its LMUs. 
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5.5.3 CBC 

For Location Services, when a Cell Broadcast Center (CBC) is associated with a BSC, the SMLC may interface to a 
CBC in order to broadcast assistance data using existing cell broadcast capabilities. The SMLC shall behave as a user, 
Cell Broadcast Entity, to the CBC (refer to 3GPP TS 23.041). 

5.5.4 LMU 

The LCS Measurement Unit (LMU) entity makes measurements (e.g. of radio signals) and communicates these 
measurements to the SMLC (e.g. the PRCF). The LMU contains a PSMF and may also perform calculations associated 
with the measurements. The LMU may make its measurements in response to requests (e.g. from the SMLC), or it may 
autonomously measure and report regularly (e.g. timing of BTS transmissions) or when there are significant changes in 
radio conditions (e.g. changes in the RTD). There may be one or more LMUs associated with the SMLC and an LCS 
request may involve measurements by one or more LMUs. LMU functionality may be integrated in a BTS. 

An LMU makes radio measurements to support one or more positioning methods; these assistance measurements are 
specific to all MSs in a certain geographic area. All location and assistance measurements obtained by an LMU are 
supplied to the SMLC associated with the LMU. Instructions concerning the timing, the nature, and any periodicity of 
these measurements are either provided by the SMLC or are pre-administered in the LMU. 

The following assistance measurement obtained by an LMU has a generic status usable by more than one position 
method: 

Radio Interface Timing measurements - comprise Absolute Time Differences (ATDs) or Real Time Differences 
(RTDs) of the signals transmitted by Base Stations, where timing differences are measured relative to either 
some absolute time difference (ATD) or the signals of another Base Station (RTD). 

5.5.5 MS 

The MS interacts with the measurement co-ordination functions to make measurements of downlink signals. The 
measurements to be made will be determined by the chosen location method. 

The MS may also contain LCS applications, or access an LCS application through communication with a network 
accessed by the MS or an application residing in the MS and/or satellite signals. The MS may include the needed 
measurement and calculation functions to determine the MS's location with or without assistance of the GERAN LCS 
entities. 



6 Signalling Protocols and Interfaces 

6.1 Protocol layering in A/Gb mode 
6.1.1 Generic Signalling Model 

Figure 4 shows the generic signalling model applicable to LCS for signalling interaction in which an SMLC forms at 
least one of the signalling end points. 
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Figure 4: Generic Model for LCS Signalling to an SMLC 



The functions performed by each protocol layer are as follows: 

a) LCS application protocol - this depends on the other signalling end point (e.g. whether a target MS or LMU) and 
may be absent if supported in the BSSAP-LE layer. The application protocol supports specific LCS functions 
(e.g. positioning measurements, assistance measurements) and is independent of lower protocol layers. 

b) BSSAP-LE - this is an extension of BSSAP and carries the LCS application protocol signaling units. Necessary 
functions include identification of the LCS application protocol and identification, where not provided by the 
network layer, of the two end points. This layer can be relayed by an intermediate entity or mapped into an 
equivalent layer 3 protocol used by the other signaling end point. This layer supports segmentation of LCS 
application layer protocols. 

c) Network Layer - provides signaling transport between the SMLC and either the other end point or some 
intermediate entity at which the BSSAP-LE layer is relayed or mapped. The network layer may support 
connection oriented or connectionless signaling. For second generation circuit oriented applications, the network 
layer is provided using either MTP or M3UA/SCTP and SCCP. This layer supports segmentation of LCS 
application layer protocols. 

d) Physical Layer - When MTP is used as transport protocol, SS7 signaling links are supported by the physical 
layer. It is recommended that when IP transport (via M3UA/SCTP) is used, the data link layer is implemented 
using Ethernet. A node using IP transport having interfaces connected via low bandwidth PPP links like El/Tl 
shall also support IP Header Compression [37] and the PPP extensions ML/MC-PPP [38], [39]. In this case, the 
negotiation of header compression [37] over PPP shall be performed according to [40]. 

e) L3 - a protocol layer compatible with or the same as BSSAP-LE. 

f) L2 - logical link layer for the other endpoint 

g) LI - physical layer for the other end point. 

6.1 .2 Message Segmentation in A/Gb mode 

Message segmentation is needed to transport any large LCS message that exceeds the message size limitation supported 
by any GSM interface over which transport is needed. 



6.1.2.1 



Network Level Segmentation 



Segmentation and reassembly of large SMLCPP messages at the network (e.g. SCCP) level may be supported. For 
message transfer over any interface where network level segmentation is not supported, segmentation at the application 
level shall be used. This may require support of both network and intermediate level segmentation by certain 
intermediate entities. 
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6.1.2.2 



Intermediate Level Segmentation 



The segmentation of SMLCPP 3GPP TS 48.031 [19], messages is supported by segmentation mechanisms defined in 
3GPP TS 48.008 [18], and 3GPP TS 49.031[22]. The sending, receiving and all intermediate entities supporting 
segmentation shall ensure reliable and sequenced delivery of the message segments by appropriate use of the 
capabilities supported by lower transport and network level protocols. 

For support of legacy (Rel4 and older) MS and GERAN, there are segmentation mechanisms defined in the RR layer 
(3GPP TS 44.018 [14]) and BSSAP-LE layer (3GPP TS 49.031 [22]) for segmentation of RRLP (3GPP TS 44.031) 
messages, which need to be supported by the MS, BSS, and SMLC in the uplink direction in the CS domain and by the 
MS and BSS for the downlink direction in the CS domain. 



6.1.2.3 



RRLP Pseudo-Segmentation 



The use of several RRLP messages to deliver a large amount of information is called "RRLP pseudo-segmentation". If 
more information than what fits in the RRLP maximum PDU size needs to be delivered, the RRLP pseudo- 
segmentation shall be used. (For Rel 4 or older MS and GERAN, may also use intermediate level segmentation). 

6.1 .3 Signalling between an SMLC, MSC and BSC 

An SMLC can either be separate logical entity or integrated functionality in the BSC. If the SMLC is a separate logical 
entity, the LCS signalling between SMLC and MSC is accomplished through the A and Lb interfaces. If the SMLC is 
integrated, the LCS signalling is accomplished through the A interface only. Figure 5 shows the protocol layers used to 
support LCS signaling between the SMLC, MSC and BSC. 




LSCF 
BSSAP 



Network 
Layer 



Physical 
Layer 



BSSLAP 



BSSAP 


BSSAP-LE 


Network 
Layer 


Network 
Layer 


Physical 
Layer 


Physical 
Layer 



MSC 



BSC 



Lb 



BSSLAP 



BSSAP-LE 



Network 
Layer 



Physical 
ayer 



SMLC 



Figure 5: Signalling Protocols between SIUILC, MSC and BSC 

6.1 .3a Signalling between an SMLC, SGSN and BSS 

An SMLC can either be separate logical entity or integrated functionality in the BSS. If the SMLC is a separate logical 
entity, the LCS signalling between SMLC and SGSN is accomplished through the Gb and Lb interfaces. If the SMLC is 
integrated, the LCS signalling is accomplished through the Gb interface only. Figure 5a shows the protocol layers used 
to support LCS signaling between the SMLC, SGSN and BSS. Notice that the Network Service layer may be based on 
frame relay or IP (see 3GPP TS 48.016 [24]). 
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Figure 5a: Signalling Protocols between SMLC, SGSN and BSS 



6.1 .4 Signaling between SMLC and MS 



SMLC Signalling to a target MS is accomplished through the Um interface. Figure 6 shows the protocol layers used to 
support signaling between an SMLC and target MS in the CS domain. 
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Figure 6: Signalling between an SMLC and Target MS in CS domain 

Figure 6a shows the protocol layers used to support signaling between an SMLC and target MS in the PS domain. The 
signalling is routed through the core network to utilize standard GPRS functions. BSSGP is specified in 
3GPP TS 48.018 [25] and RLC/MAC is specified in 3GPP TS 44.060 [28]. The TOM and LLC protocols are specified 
in 3GPP TS 44.064 [26]. The TOM Protocol Header for RRLP is specified in 44.031 [15]. For an overview of GPRS, 
see 3GPP TS 23.060 [27]. 
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Figure 6a: Signalling between an SMLC and Target MS in PS domain 

6.1.5 SMLC Signalling to a Type A LMU 

Notice that the signalHng to a Type A LMU is using CS signalUng over the Um interface. A Type A LMU can be used 
to support positioning of mobile stations both in the CS and the PS domain. 



6.1.5.1 



Circuit Switched Signalling using an SDCCH 



Figure 7 shows the protocol layers used to support signaling between an SMLC and a Type A LMU, using an SDCCH 
on the Um interface. 
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Figure 7: Signalling between an SMLC and Type A LMU using an SDCCH 



Signalling using a TCH 



Figure 8 shows the protocol layers that can be used to support signaling between an SMLC and a Type A LMU using a 
TCH on the Um interface. The TCH is assumed to support either transparent or non- transparent synchronous data and 
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may be provided in a multislot configuration. The main usage would be for O&M data and SW download - e.g. during 
offpeak hours. 
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Figure 8: Signalling between an SMLC and a Type A LMU using a TCH 

6.1.6 SMLC signalling to a Type B LMU 

The protocol layers employed to enable signaling between the SMLC and a Type B LMU are shown in figure 9. Notice 
that the signalling to a Type B LMU can be used to support positioning of mobile stations both in the CS and the PS 
domain. 
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Figure 9: Signalling between an SMLC and Type B LMU 

NOTE*: Abis interface is beyond the scope of the present document. 
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6.1.7 SMLC Signalling to a peer SMLC 



The protocol layers used for SMLC to SMLC signalling are shown in figure 10, where it is assumed that both SMLCs 
have connections to an intermediary signalling network (or there is a direct link between the SMLCs). 



SMLCPP 
(48.031) 


















w 


BSSAP-LE 
(49.031) 




•4 — ► 








w 


""■"-^^ Relay^^^^ 




^^--..Relay^^^ 




Network 
Layer 


Network 
Layer 


Network 
Layer 


Network 
Layer 


Network 
Layer 


^ — ^ 






Physical 
Layer 


Physical 
Layer 


Physical 
Layer 


Physical 
Layer 


Physical 
Layer 











SMLC 



Network 
Relay 



Network 
Relay 



SMLCPP 
(48.031) 



BSSAP-LE 
(49.031) 



Network 
Layer 



Physical 
Layer 



SMLC 



Figure 10: SMLC to SMLC Signalling via an intermediary signalling network 

In the absence of either a direct link or links to an intermediary signalling network, signalling can go via attached BSCs 
and MSCs as shown in figure 1 1 for signalling between the SMLCs sharing the same MSC. 
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Figure 1 1 : SMLC to SMLC Signalling via associated BSCs and MSC 



6.2 Protocol layering in lu mode 

6.2.1 Signalling between SMLC and MSC/SGSN 

A SMLC can either be a separate logical entity or integrated functionality in the BSC. If the SMLC is a separate logical 
entity, the LCS signalling between SMLC and MSC/SGSN is accomplished through the lu and Lb interfaces. If the 
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SMLC is integrated, the LCS signalling is accomplished through the lu interface only. Figure 11a shows the protocol 
layers used to support LCS signaling between the SMLC, BSC and MSC/SGSN. 
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additional transport layer options. 

Figure 11a: Signalling Protocols between SMLC, BSC and MSC/SGSN 

6.2.2 Signalling between SMLC and MS 

SMLC Signalling to a target MS is accomplished through the Um interface. Figure lib shows the protocol layers used 
to support signaling between an SMLC and target MS. 
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Figure lib: Signalling between an SMLC and Target MS 
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6.2.3 SMLC signalling to a Type A LMU 

The signalling to a Type A LMU is defined using A/Gb Mode CS signalling over the Um interface, see Clause 6.1.5. A 
Type A LMU operating in A/Gb Mode CS Domain can be used to support positioning of mobile stations operating in lu 
Mode. Signalling to a Type A LMU in lu Mode is FFS. 

6.2.4 SMLC signalling to a Type B LMU 

The signalling to a Type B LMU is defined in Clause 6. 1 .6. A Type B LMU operates independently of the mode of the 
MS (A/Gb Mode or lu Mode) and signalling to a Type B LMU as defined in Clause 6.1.6 can be used to support 
positioning of mobile stations operating in lu Mode. 



6.2.5 SMLC signalling to a peer SMLC 



The signalling to a peer SMLC is defined in Clause 6.1.7. A peer SMLC connection and signaling is independent of the 
mode of the MS (A/Gb Mode or lu Mode) and signalling to a peer SMLC as defined in Clause 6.1.7 can be used to 
support positioning of mobile stations operating in lu Mode. 



7 GERAN Network Location Procedures 

7.1 State description for SIVILC 

7.1.1 SMLC States 

7.1.1.1 NULL state 

This is a conceptual rather than actual state in which a certain location request from a particular Location Client, 
VMSC, SGSN or BSC either has not yet been received or has been completed. 

7.1.1.2 LOCATION State 

This state exists after the SMLC has received a location request from a BSC and persists while the SMLC is obtaining 
position measurements for a particular positioning method until such time as positioning measurements have been 
received and a location estimate (with optional velocity estimate) has been computed and returned to the BSC. 

When sufficient positioning measurement results have been received, the SMLC either evaluates them, if they include 
an already computed location estimate, or uses them to compute a location estimate. The SMLC then has the option of 
either reinitiating another positioning attempt, e.g. if the location estimate did not satisfy the required QoS and the 
requirement on response time permits another position attempt, or returning the location estimate to the BSC. 
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7.1.2 State Functionality 
7.1.2.1 State Transitions 



Location Request 
from a BSC 




Return Location 
Result to BSC or 
Timeout 



Initiate Positioning 
via BSC 

Figure 12: State Transitions in the SIVILC 

Moving from NULL to LOCATION state: After a location request is received from the BSC, the SMLC enters the 
LOCATION state. It then chooses a positioning method and initiates the appropriate position measurements. 

Moving from LOCATION to NULL state: When the SMLC has obtained a location estimate that best meets the 
requested QoS parameters, it returns this to the BSC and re-enters the NULL state. 



7.1.2.2 



LOCATION Timer Function 



The SMLC runs a timer while in the LOCATION state to limit the total amount of time that positioning can be active. 
This timer should be related to any response time indicated in the location request QoS parameters. If the timer expires 
before a final location estimate has been produced, the SMLC either returns the best existing location estimate (with 
optional velocity estimate) to the BSC (e.g. an estimate based on the current cell ID) or returns a failure indication. It 
then re-enters the NULL state. 



7.2 State Description for the BSC 

7.2.1 BSC States 
7.2.1.1 IDLE state 

In this state, the BSC location service is inactive for a particular MS. 



7.2.1.2 



LOCATION State 



In this state, the BSC is awaiting a response from an SMLC after requesting the location for a particular MS. In this 
state, a Radio Resource connection to the target MS will be active - allowing the SMLC and MS to exchange 
positioning related messages for mobile based and mobile assisted position methods. For certain position methods 
(e.g. network based position methods), the SMLC may invoke substates in the BSC during which other types of 
association or procedure are supported with the MS (e.g. temporary call establishment, handover). In this state, the BSC 
may transfer positioning related messages between the SMLC and the target MS and/or between the SMLC and certain 
LMUs served by the BSC. 
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7.2.2 State Functionality 
7.2.2.1 State Transitions 



Request Location 
from SMLC 




Receive Location 
results from tine SIVILC 
or Timeout 



Transfer Positioning 
IVIessages 

Figure 13: State Transitions in the BSC 

Moving from IDLE to LOCATION state: After a request has been received to locate a particular MS served by the 
BSC, a location request is sent to the SMLC associated with the serving cell: the BSC then enters the LOCATION state. 
Before entering this state, a Radio Resource connection to the MS must have been already established by the VMSC. 

Moving from LOCATION to IDLE state: After the return of a location estimate result from the SMLC, the BSC shall 
re-enter IDLE state. 



7.2.2.2 



LOCATION Timer Function 



The BSC runs a timer while in the LOCATION state to limit the amount of time waiting for a location response from 
the SMLC. If the timer expires before such information is received, the BSC indicates a location failure to the original 
requesting entity and re-enters IDLE state. 

7.3 Usage of SCCP Connection on the Lb interface in the CS 
domain in A/Gb mode 

SCCP connection oriented signalling between an SMLC and a BSC is used to support SMLC signalling to a Type A 
LMU, a serving BSC, or a target MS. The types of SCCP connections are described below. 

7.3.1 SCCP Connection for positioning of a target MS 

The BSC establishes this connection when a request is received for a location estimate for a target MS in the CS 
domain. The BSC sends the BSSAP-LE Perform Location Request to the SMLC inside an SCCP Connection Request 
message. Signaling between the SMLC and target MS, if required, is then relayed by the BSC between this SCCP 
connection and the main signaling link to the MS. The same SCCP connection is also used to transfer BSSLAP 
messages between the SMLC and serving BSC. See Figure 14. 
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Figure 14: SCCP based signalling for MS positioning with an SMLC in CS domain 

7.3.2 SCCP connection to access a Type A LMU 

The BSC or SMLC establishes this connection to enable LCS messages to be transferred to or from a Type A LMU. 
The BSC or SMLC sends a BSSAP-LE LMU Connection Request message inside an SCCP Connection Request 
message. Signaling is subsequently relayed through the BSC using this SCCP connection as shown in figure 15. 
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Figure 15: SCCP based signalling to access a Type A LMU with an SMLC 

Usage of SCCP Connection on tine Lb interface in the PS 
domain in A/Gb mode 



SCCP connection oriented signalling between an SMLC and a BSS is used to support SMLC signalling to a serving 
BSS or a target MS. The types of SCCP connections are described below. 

7.4.1 SCCP Connection for positioning of a target IVIS 

The BSS establishes this connection when a request is received for a location estimate for a target MS in the PS domain. 
The BSS sends the BSSAP-LE Perform Location Request to the SMLC inside an SCCP Connection Request message. 
Signaling between the SMLC and target MS is then relayed by the BSS via the SGSN to the MS. The same SCCP 
connection is also used to transfer BSSLAP messages between the SMLC and serving BSS. See figure 15a below. 
RRLP Messages between the SMLC and the MS are carried in BSSGP Position Command/Response messages (see 
3GPP TS 48.018) across the Gb interface and in TOM messages in LLC UI frames (see 3GPP TS 44.064 [26]) across 
the Um interface. Because a connectionless mode of communication is used to transport BSSGP and LLC, an MS 
identity is included in each message for those protocols. 
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Figure 15a: SCCP based signalling for MS positioning with an SMLC in PS domain 



8 Common Procedures to Support Positioning 

The procedures described in this clause enable an SMLC to obtain positioning related information or instigate 
positioning for a particular target MS. The procedures are applicable to all positioning methods after an SMLC receives 
a BSSAP-LE Perform Location request for a target MS until a BSSAP-LE Perform Location response is returned to the 
originator. 

8.1 Information Transfer between an SIVILC and a Target MS in 
the CS Domain in A/Gb mode for E-OTD and A-GNSS 
positioning methods 

An SMLC uses the procedure shown below in order to obtain the MS position or positioning measurements from a 
target MS or transfer location assistance information to a target MSin the CS domain after a request has been received 
from the BSC serving the target MS. More details of the location information transfer procedure between the BSC and 
MS can be found in 3GPP TS 24.008. 
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Figure 16: Information Transfer between an SMLC and a Target MS in CS domain 

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the serving BSC containing an 
embedded BSSLAP MS Position Command with an RRLP message parameter. The message is transferred using 
the SCCP connection established between the SMLC and BSC for positioning the target MS If the BSSLAP 
message is too large to fit in a single BSSAP-LE Connection Oriented Information message, RRLP 
pseudo-segmentation shall be used. Legacy SMLC may utilize BSSAP-LE layer segmentation instead of RRLP 
pseudo-segmentation. The SMLC shall indicate in the first BSSLAP MS Position Command whether the 
embedded RRLP message contains a positioning command versus positioning assistance data. 
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2) The BSC transfers the embedded RRLP message to the target MS inside an RR Application Information 
message. No later than when the RR Application Information message has been transferred, the BSC shall start a 
positioning supervision timer if none is already in progress or restart this if already in progress. If the timer 
expires before the final response in step 3 is received, the BSC shall return a BSSAP-LE Connection oriented 
Information message to the SMLC containing a BSSLAP Abort with a cause of BSC timeout. 

3) When the target MS has positioning information to return to the SMLC, it sends an RR Application Information 
message to the BSC containing an embedded RRLP message. If the RRLP message is too large to fit in a single 
RR Application Information message, RRLP pseudo-segmentation shall be used. Legacy MS may utilize RR 
layer segmentation instead of RRLP pseudo-segmentation. . The last RR Application Information message shall 
indicate if this is the final response from the MS. 

4) If the timer started in step 2 has already expired, the BSC discards the RRLP message received in step 3. 
Otherwise, the BSC forwards the RRLP message to the SMLC inside a BSSLAP MS Positioning Response 
message contained in a BSSAP-LE Connection Oriented Information message. If the SMLC indicated a 
positioning command in step 1 and the MS has indicated a final response, the BSC may add additional 
measurement information to the BSSLAP MS Position Response in the last BSSAP-LE message - if necessary, 
creating a new BSSAP-LE message if message size limitations would be exceeded. The BSC shall stop the 
supervision timer started in step 2 when the final segment of the final response from the MS has been 
transferred. If the MS did not indicate a final response in step 3, the SMLC may transfer a further RRLP message 
to the MS (e.g. containing assistance data) according to steps 1 and 2 and the MS may return a subsequent 
response according to steps 3 and 4. 

8.1 a Information Transfer between an SMLC and a Target MS in 
the PS Domain in A/Gb mode 

An SMLC uses the procedure shown below in order to obtain the MS position or positioning measurements from a 
target MS or transfer location assistance information to a target MS in the PS domain after a request has been received 
from the BSS serving the target MS. 
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Figure 16a: Information Transfer between an SMLC and a Target MS in PS Domain 

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the serving BSS containing an 
embedded BSSLAP MS Position Command with an RRLP message parameter. The message is transferred 
using the SCCP connection established between the SMLC and BSS for positioning the target MS. If the RRLP 
message is larger than the RRLP maximum PDU size, RRLP pseudo-segmentation shall be used. The SMLC 
shall indicate in the positioning command bit in the RRLP flags IE in the BSSLAP MS Position Command 
whether the embedded RRLP message contains a positioning command versus a non-command - e.g. 
positioning assistance data. 
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2) The BSS relays the embedded RRLP message and the RRLP flags IE to the SGSN inside a BSSGP Position 
Command message. When the BSSGP Position Command message has been transferred, the BSS shall start a 
positioning supervision timer if not already in progress or restart if the timer is already in progress. If the timer 
expires before the final response in step 5 is received, the BSS shall return a BSSAP-LE Connection Oriented 
Information message to the SMLC containing a BSSLAP Abort with a cause of BSS timeout. 

3) The SGSN receives the RRLP message in the BSSGP Position Command message and relays it to the MS in an 
LLC UI frame. The TOM protocol with SAPI TOMS is used for transfer of RRLP messages. The positioning 
command bit from the RRLP flags IE in the BSSGP message is also relayed using the C/R bit in the TOM 
header (see 3GPP TS 44.031 [15]). The received C/R bit may be ignored by the MS or used for implementation 
purposes. 

4) When the target MS has positioning information to return to the SMLC, it sends an LLC UI Frame to the SGSN 
containing an embedded RRLP message. The TOM protocol is used for transfer of RRLP messages. If the 
RRLP message is larger than the RRLP maximum PDU size, RRLP pseudo-segmentation shall be used. If the 
RRLP pseudo-segmentation is used, the MS shall send several RRLP messages. In each message the MS shall 
indicate in the C/R bit in the TOM protocol header whether it is the final response or not. The final response 
shall be the last RRLP message that the MS expects to send in response to RRLP messages received so far from 
the SMLC. In the final message the MS shall indicate that it is the final response by setting the appropriate 
RRLP flag. 

5) The SGSN relays the RRLP message to the BSS. The RRLP message is sent in a BSSG Position Response 
message. The C/R bit from the TOM header is relayed using the final response bit in the RRLP flags IE in the 
BSSGP message. 

6) If the timer started in step 2 has already expired, the BSS discards the RRLP message received in step 5. 
Otherwise, the BSS relays the RRLP message and the RRLP flags IE to the SMLC inside a BSSLAP MS 
Positioning Response message contained in a BSSAP-LE Connection Oriented Information message. If the 
SMLC indicated a positioning command in the most recent message to be transferred in step 1 and the MS has 
indicated a final response, the BSS may add additional measurement information to the BSSLAP MS Position 
Response in the last BSSAP-LE message. The BSS shall stop the supervision timer started in step 2 when the 
final response from the MS has been transferred. The SMLC may transfer a further RRLP message to the MS 
(e.g. containing assistance data or a positioning command) according to steps 1, 2, and 3 and the MS may return 
a subsequent response according to steps 4, 5, and 6. Steps 4-6 are repeated if the RRLP pseudo-segmentation is 
used for the uplink message. 

8.1 b Information Transfer between an SMLC and a Target MS in 
lu Mode 

An SMLC uses the procedure shown below in order to obtain the MS position or positioning measurements from a 
target MS or transfer location assistance information to a target MS after a request has been received from the BSC 
serving the target MS. More details of the location information transfer procedure between the BSC and MS can be 
found in 3GPPTS 44.1 18. 
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Figure 16b: Information Transfer between an SMLC and a Target MS 
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1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the serving BSC containing an 
embedded BSSLAP MS Position Command with an RRLP message parameter. The message is transferred using 
the SCCP connection estabHshed between the SMLC and BSC for positioning the target MS If the BSSLAP 
message is too large to fit in a single BSSAP-LE Connection Oriented Information message, RRLP 
pseudo-segmentation shall be used. The SMLC shall indicate in the first BSSLAP MS Position Command 
whether the embedded RRLP message contains a positioning command versus positioning assistance data. 

2) The BSC transfers the embedded RRLP message to the target MS inside an RRC LCS DL Information message. 
No later than when the RRC LCS DL Information message has been transferred, the BSC shall start a 
positioning supervision timer if none is already in progress or restart this if already in progress. If the timer 
expires before the final response in step 3 is received, the BSC shall return a BSSAP-LE Connection oriented 
Information message to the SMLC containing a BSSLAP Abort with a cause of BSC timeout. 

3) When the target MS has positioning information to return to the SMLC, it sends an RRC LCS UL Information 
message to the BSC containing an embedded RRLP message. If the RRLP message is too large to fit in a single 
RRC LCS UL Information message, RRLP pseudo-segmentation shall be used. The last RRC LCS UL 
Information message shall indicate if this is the final response from the MS. 

4) If the timer started in step 2 has already expired, the BSC discards the RRLP message received in step 3. 
Otherwise, the BSC forwards the RRLP message to the SMLC inside a BSSLAP MS Positioning Response 
message contained in a BSSAP-LE Connection Oriented Information message. If the SMLC indicated a 
positioning command in step 1 and the MS has indicated a final response, the BSC may add additional 
measurement information to the BSSLAP MS Position Response in the last BSSAP-LE message - if necessary, 
creating a new BSSAP-LE message if message size limitations would be exceeded. The BSC shall stop the 
supervision timer started in step 2 when the final response from the MS has been transferred. If the MS did not 
indicate a final response in step 2, the SMLC may transfer a further RRLP message to the MS (e.g. containing 
assistance data) according to steps 1 and 2 and the MS may return a subsequent response according to steps 3 
and 4. 

8.2 Information Transfer between an SMLC and a BSC 

An SMLC uses the procedure shown below in order to obtain positioning related information from the BSC serving a 
particular target MS after a positioning request has been received from the BSC. This procedure applies to positioning 
of an MS in both the CS and the PS domains. 
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Figure 17: Information Transfer between an SMLC and a BSC 

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the BSC containing an embedded 
BSSLAP message. The BSSAP-LE message is transferred using the SCCP connection previously established 
between the SMLC and BSC when the positioning request for the target MS was initially sent to the SMLC. The 
BSC recognizes that it is the final destination due to the presence of the embedded BSSLAP message. 

2) When the BSC has positioning information for the target MS to return to the SMLC, it sends a BSSAP-LE 
Connection Oriented Information message to the SMLC containing an embedded BSSLAP message. The 
message is sent using the SCCP connection previously established for positioning the target MS. 

8.3 Common Procedures to Support Access to an LMU 

The procedures in this clause support the transfer of positioning related information and O&M data between an SMLC 
and a particular LMU associated with the SMLC. These procedures apply to positioning of an MS in both the CS and 
the PS domains. 
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8.3.1 Location Update Procedure between an SMLC and a Type A LMU 

The following procedure supports a normal location update from the perspective of a Type A LMU. The location update 
can occur periodically, on power up, following recovery from some failure condition and when an LMU in idle mode 
detects that its closest BTS is in another location area. 



SMLC 



BSC 



2. SCCPCR[BSSMAP Corr plete Layer 3 
Information [Location Updating Request]] 



3. Normal GSM Autt 



4. DTAP Location Updating 



LMU 



1 . DTAP Location Updatinc 



entication, Ciphering 
Accept 



5. DTAP Location Updatin j Accept 



Request 



Figure 18: Location Update Procedure between an SIVILC and a Type A LIVIU 

1) If the LMU does not currently have a signaling link, it sends an RR Channel Request to the serving BTS to 
request a SDCCH. The RR Channel Request contains an establishment cause identifying an LMU. After 
assignment of the SDCCH, the LMU sends a DTAP Location Updating request to the BSC. This shall indicate 
that a follow on request is pending if the LMU has more data to send. 

2) Because the BSC serving the LMU is associated with an SMLC and the Channel Request message contained an 
LMU establishment cause, the BSC forwards the Location Updating request to the SMLC rather than MSC. If 
there was previously no SDCCH, this is sent inside a BSSMAP Complete Layer 3 Information message that is 
contained in an SCCP Connection Request. 

3) The SMLC performs normal authentication and ciphering if needed for the LMU. The SMLC shall not assign a 
TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS by a VLR. 

4) The SMLC returns a DTAP Location Updating Accept to the BSC. Unless the LMU indicated a follow on 
request, the SMLC may then initiate release of the SDCCH. 

5) The BSC forwards the DTAP message to the LMU. 

8.3.2 IMSI Detach Procedure between an SMLC and a Type A LMU 

The following procedure supports a normal IMSI Detach from the perspective of a Type A LMU. This may be 
instigated if the LMU is to be deactivated - e.g. for offline maintenance. 



SMLC 



BSC 



2. SCCPCR[BSSMAP Cor iplete Layer 3 
Information [IMSI Detact Indication]] 



LMU 



1 . DTAP IMSI Detach Indie ation 



Figure 19: IIVISI Detach Procedure between an SIVILC and a TypeA LMU 

1) If the LMU does not currently have a signaling link, it sends an RR Channel Request to the serving BTS to 
request a SDCCH. The RR Channel Request contains an establishment cause identifying an LMU. After 
assignment of the SDCCH, the LMU sends a DTAP IMSI Detach Indication to the BSC. 
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2) Because the BSC serving the LMU is associated with an SMLC and the Channel Request message contained an 
LMU establishment cause, the BSC forwards the IMSI Detach Indication to the SMLC rather than MSC. If there 
was previously no SDCCH, this is sent inside a BSSAP Complete Layer 3 Information message that is contained 
in an SCCP Connection Request. The SMLC marks the LMU as temporarily inactive and initiates release of the 
SDCCH. 

8.3.3 LCS Information Transfer between an SMLC and a Type A LMU 
8.3.3.1 Information Transfer using an SDCCH 

The following procedure supports information transfer between an SMLC and a Type A LMU. 
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Figure 20: Information Transfer between an SIVILC and a Type A LMU 

1) If there is no signaling Unk yet for an LMU between the SMLC and the BSC serving the LMU, the SMLC sends 
a BSSAP Paging message to the serving BSC inside an SCCP Unitdata message. 

2) The serving BSC broadcasts an RR Paging Request. 

3) The LMU sends a Channel Request message containing an LMU establishment cause to request an SDCCH. 
After assignment of the SDCCH, the LMU returns an RR Paging Response. 

4) Because the BSC serving the LMU is associated with an SMLC and the Channel Request message in step 3 
contained an LMU establishment cause, the BSC transfers the Paging Response to the SMLC, rather than MSC, 
in a BSSAP Complete Layer 3 Information message contained in an SCCP Connection Request. 

5) The SMLC performs normal authentication and ciphering if this is needed for the LMU. The SMLC shall not 
assign a TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS by a VLR. 
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6) If the SMLC needs to send data to the LMU, it may send one or more DTAP-LE REGISTER, FACILITY or 
RELEASE COMPLETE messages to the BSC. Each DTAP-LE message contains an embedded LLP message 
and an indication of whether release of the SDCCH by the LMU is forbidden. Each DTAP-LE message is 
transferred by the BSC to the LMU. 

7) The SMLC may initiate release of the SDCCH to the LMU by sending a ESS AP Clear Command to the BSC. 

8) The BSC returns a BSSAP Clear Complete. 

9) The BSC orders release of the SDCCH by sending an RR Channel Release to the LMU. 

10)The SMLC releases the SCCP connection to the BSC by sending an SCCP Released message. 

1 1) When the LMU has LCS data to send and does not currently have a signaling link, it sends an RR Channel 
Request to the serving BTS to request an SDCCH. The RR Channel Request contains an establishment cause 
identifying an LMU. After assignment of the SDCCH, the LMU sends a DTAP CM Service request to the 
serving BSC. 

12)Because the BSC serving the LMU is associated with an SMLC and the Channel Request message contained an 
LMU establishment cause, the BSC forwards the CM Service Request with an indication that this came from an 
LMU to the SMLC, rather than MSC, inside a BSSAP Complete Layer 3 Information message that is contained 
in an SCCP Connection Request. 

13) The SMLC performs authentication and ciphering if needed for the LMU. Otherwise, a CM Service Accept is 
returned. The SMLC shall not assign a TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS 
by a VLR. 

14) The LMU sends one or more DTAP-LE REGISTER, FACILITY or RELEASE COMPLETE messages to the 
serving BSC each containing an embedded LLP message. The BSC forwards each DTAP-LE message to the 
SMLC. 
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8.3.3.2 Information Transfer using a TCH 
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Figure 21 : Information Transfer between an SMLC and a Type A LMU using a TCH 

1) The SMLC establishes a signaUng connection to the LMU using an SDCCH. 

2) The SMLC sends a DTAP Setup to the LMU with the requested bearer capability. 

3) The LMU returns a DTAP Call Confirmed. 

4) The SMLC initiates traffic channel assignment by sending a BSSAP Assignment Request to the BSC. 

5) The BSC requests channel activation in the BTS and then sends an RR Assignment Command to the LMU. 

6) The LMU acknowledges TCH assignment. 

7) The BSC confirms TCH assignment. 

8) The LMU confirms call establishment. 

9) The SMLC acknowledges the LMU confirm. 

10) DTAP-LE Connection Oriented Information messages are transferred between the SMLC and LMU on the 
established TCH: these are transparent to the BSC. 

1 l)The SMLC initiates release of the TCH by sending a DTAP Disconnect to the LMU 

12) The LMU returns a DTAP Release. 

13) The SMLC sends a DTAP Release Complete. 

14) The SMLC initiates release of the TCH by sending a BSSAP Clear Command to the BSC. 
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15)The BSC returns a BSSAP Clear Complete. 

16) The BSC orders release of the TCH by sending an RR Channel Release to the LMU. 

17) The SMLC releases the SCCP connection to the BSC by sending an SCCP Released message. 

8.3.4 LCS Information Transfer between an SMLC and a Type B LMU 

A SMLC uses the procedure shown below in order to exchange LCS information with a TypeB LMU. 



SMLC 



BSC 



1.SCCP UDT [BSSAP-LE 
Connectionless Information] 



BTS or LMU 



2. Location Information 



3. Location Information 



4. SCCP UDT [BSSAP-LE 
Connectionless Information] 

Figure 22: Information Transfer between a SIVILC and a Type B LMU 

1) The SMLC passes a BSSAP-LE Connectionless Information message to the BSC containing an embedded LLP 
message and the LAC/CI cell address identifying the LMU. The BSSAP-LE message is transferred inside an 
SCCP Unitdata message. 

2) The BSC transfers the embedded LLP message to either the BTS associated with the LMU or the LMU itself 
inside a Location Information message. The BTS or LMU is identified using the LAC/Cl received in step L 

3) When the LMU has positioning information to return to the SMLC, either it or its associated BTS transfers this 
to the BSC inside a Location Information message.. 

4) The serving BSC forwards the LLP message to the SMLC inside a BSSAP-LE Connectionless Information 
message contained in an SCCP Unitdata message. The BSSAP-LE message contains the LAC/CI address 
identifying the LMU. 



8.4 



Common Control Procedures for LMUs 



These procedures are applicable to any Type A LMU and may be used for any Type B LMU to enable control of the 
LMU by its associated SMLC. The procedures assume support for the establishment of a signaling link and the transfer 
of LLP messages between an SMLC and LMU that are defined in the common procedures to support access to an LMU, 
clause 8.3. Consequently, details of signaling link establishment and message transfer by a BSC and BTS are not 
shown. 
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8.4.1 Reset Procedure 

The reset procedure enables an SMLC to return an LMU to a known initial state in which no measurement or O&M 
operations are outstanding or being performed. 



SMLC 



BSC 



1. LLP Reset Invoke 



2. LLP Reset Rsturn Result 



LMU 



message 



Figure 23: Reset Procedure for a Circuit IVIode LIVIU 

1) After first establishing a signaling connection to the LMU (see clause 8.3), the SMLC sends an LLP Reset 
Invoke to the LMU via BSC. 

2) The LMU cancels any LCS measurement and O&M tasks previously ordered by the SMLC. The LMU then 
returns an LLP Reset Return Result to the SMLC. 

8.4.2 Status Query Procedure 

The Status Query procedure enables an SMLC to verify the status of an associated LMU. The procedure may be 
instigated periodically or following any loss of communication with the LMU. 



SMLC 



BSC 



1 . LLP Status Query 



2. LLP Status Que y Return Result 



LMU 



Invoke message 



Figure 24: Status Query Procedure for a Circuit lUlode LIUlU 

1) After first establishing a signaling connection to the LMU (see clause 8.3), the SMLC sends an LLP Status 
Query Invoke to the LMU via BSC. 

2) The LMU returns an LLP Status Query return result, indicating the number of active measurement jobs for each 
type of measurement (e.g. RIT) and the number of active O&M jobs in the LMU that were previously ordered by 
the SMLC. 

8.4.3 Status Update Procedure 

The Status Update procedure enables an LMU to report status information to its associated SMLC. The procedure may 
be instigated for the following reasons: 

1 . Periodically; 

2. Power-on condition or recovery from failure with loss of memory; 

3. Impending availability or unavailability for O&M reasons; 

4. Location Update by a Type A LMU in a new Location Area. 
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SMLC 



BSC 



LLP Status Update I nvoke message 



LMU 




Figure 25: Status Update Procedure for a Circuit IVIode LIVIU 

1) After first establishing a signaling connection to the SMLC (see clause 8.3), the LMU sends an LLP Status 
Update Invoke to the SMLC via BSC. This message shall include the reason for the Status Update, the number 
of active and outstanding jobs of each category in the LMU and the current hardware status. 

2) The SMLC returns an LLP Status Update return result to acknowledge receipt of the Status Update. 



8.5 Exception Procedures 



The procedures in this clause apply to all location procedures where a BSS AP-LE Perform Location Request has been 
sent to an SMLC by a BSC requesting some location service (e.g. provision of a location estimate for a target MS or 
transfer of assistance data to a target MS). 

8.5.1 Procedures in the SMLC 

When a request for a location estimate fails due to failure of a position method itself (e.g. due to inaccurate or 
insufficient position measurements and related data) and the SMLC is unable to instigate another positioning attempt 
(e.g. due to a requirement on response time), the SMLC may return a BSSAP-LE Perform Location response containing 
a less accurate location estimate (e.g. based on serving cell and timing advance). If a less accurate estimate is not 
available, the SMLC shall instead return a BSSAP-LE Perform Location response message containing no location 
estimate and indicating the cause of failure. 

When a request for any other location service (e.g. transfer of assistance data to a target MS) fails for any reason and the 
SMLC is unable to reattempt the service, the SMLC shall return a BSSAP-LE Perform Location response message 
indicating the cause of failure. 

When a location service request is interrupted by some other unrecoverable error event inside the SMLC, the SMLC 
shall immediately terminate the location service attempt and return a BSSAP-LE Perform Location Response message 
containing the reason for the location service cancellation. In that case, any dialogue previously opened with an LMU or 
BSS for the purpose of instigating position measurements for any MS being located may also be aborted by the SMLC. 

If the SMLC receives a BSSAP-LE Perform Location Abort indication for a previous location service request from the 
BSS, it shall immediately terminate the location service attempt and may abort any dialogues used for the location 
service attempt that may still exist with any LMUs. The circumstances of the abort may still ensure cancellation of any 
such procedure (see clause on BSS). For a BSSAP-LE Perform Location Abort, the SMLC shall then either return any 
location estimate (with optional velocity estimate) already derived, if this was requested, or return a BSSAP-LE 
Perform Location response indicating failure of the location service and the cause of the failure in the BSSAP-LE 
Perform Location Abort. 

If the SMLC has instigated any location related procedure in the Target MS or its serving BSS and receives a BSSLAP 
Reject, BSSLAP Abort or BSSLAP Reset indication from the BSS, it shall cancel the location service attempt and may 
abort any dialogues for this that currently exist with any LMUs. For a BSSLAP Abort, the SMLC shall then either 
return any location estimate (with optional velocity estimate) already derived, if this was requested and is sufficient for 
the requested QoS, or return a BSSAP-LE Perform Location response indicating failure of the location service and the 
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cause of the failure in the BSSLAP Abort. For a BSSLAP Reject and BSSLAP Reset, the SMLC has the additional 
option of restarting the location service attempt and using the same or a different position method where a location 
estimate was requested. A decision to restart the location service shall take into account the cause of the location service 
failure as conveyed in the BSSLAP Reject or BSSLAP Reset and whether, in the case of successful intra-BSC 
handover, the new cell for the target MS is still associated with the SMLC. If the SMLC receives a BSSLAP Reject or 
BSSLAP Reset with a cause indicating intra-BSC handover and with a new cell identity for the target MS that is not 
associated with the SMLC, the SMLC shall return a BSSAP-LE Perform Location response containing either a location 
estimate (with optional velocity estimate), if requested and available, or a failure cause indicating "intra-BSC" 
handover. 

NOTE: In the CS domain, in the case of an intra-BSC handover to a cell in a different PLMN (different MCC, 

MNC combination), the SMLC may receive a BSSLAP Reset containing the new location area code and 
new cell ID. The SMLC may then deduce the new MCC and MNC from the uniqueness, when this 
applies, of the combined values for the new location area code and cell ID compared to the corresponding 
values for neighbouring cells. 

8.5.2 Procedures in an LMU 

An LMU shall return an error indication to its controlling SMLC when location measurements previously ordered by 
the SMLC cannot be provided due to any error condition. 

8.5.3 Procedures in tine BSC in tine CS Domain 

8.5.3.1 General Procedures 

The BSC serving a target MS shall supervise any network or MS location service procedure, including transfer of 
positioning assistance data to an MS, and shall only allow one such procedure to be active at any time. If a new 
procedure is instigated by the SMLC for any target MS, the BSC shall cancel any previous procedure without notifying 
the SMLC or target MS. The new procedure shall then be treated according to the prevailing conditions. If a location 
information transfer to an MS initiated by an SMLC is not active, the BSC shall discard any RRLP message received 
from the MS. This precludes the initiation of any location service procedure from an MS. 

Depending on the location procedure and its current state of execution, a serving BSC may chose to defer certain radio 
related events (e.g. handover) to avoid interference with location - refer to the later clauses for each position method. A 
serving BSC shall abort all existing location related procedures for a particular target MS without notifying a target MS 
if the DCCH to the target MS or the SCCP connection to the SMLC is released. In the event of an abort with an SMLC, 
the BSC shall attempt to notify the SMLC using a BSSAP-LE Perform Location Abort. 

8.5.3.2 Rejection of an SMLC Positioning Request 

The BSC may reject any request from an SMLC for positioning or transfer of assistance data for a target MS if the 
request cannot be performed for reasons other than interaction with handover or other RR management. If the request is 
rejected, the BSC shall return a BSSLAP Reject to the SMLC containing the cause of rejection. 

8.5.3.3 Interaction with Inter-BSC Handover 

The BSC shall reject any request from an SMLC for positioning or transfer of assistance data while an inter-BSC 
handover procedure is ongoing and shall return a BSSLAP Abort to the SMLC. 

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already in 
progress if inter-BSC handover is needed and is not precluded by the particular location procedure and its current state. 
When a location procedure is terminated and there is an active BSSLAP transaction, the BSC shall return a BSSLAP 
Abort message to the SMLC after the BSSAP Handover Required has been sent to the serving MSC. The BSSLAP 
Abort shall contain the cause of the location procedure failure. When a location procedure is terminated and there is no 
active BSSLAP transaction, the BSC shall send a BSSAP-LE Perform Location Abort message to the SMLC after the 
BSSMAP Handover Required has been sent to the serving MSC. 
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8.5.3.4 Interaction with Intra-BSC Handover and other RR Management Procedures 

The BSC shall reject any request from an SMLC for positioning or transfer of assistance data while an intra-BSC 
handover or other intra-BSC RR management procedure involving the target MS is ongoing and shall return a BSSLAP 
Reset to the SMLC when the handover or other RR management procedure is complete in the BSC. If the handover or 
other RR management procedure times out in the BSC, the BSC shall instead return either a BSSLAP Reset or a 
BSSLAP Abort to the SMLC. 

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already in 
progress if an intra-BSC handover or other intra-BSC RR management procedure is needed and is not precluded by the 
particular location procedure and its current state. When location procedure is terminated, the BSC shall return a 
BSSLAP Reset message to the SMLC after the intra-BSC handover or other RR management procedure is complete in 
the BSC. If the intra-BSC handover or other RR management procedure times out in the BSC, the BSC shall instead 
return either a BSSLAP Reset or a BSSLAP Abort to the SMLC. 

A BSSLAP Reset shall contain a cause indication, the current serving cell identity, the current location area code if this 
has just changed due to intra-BSC handover and may contain measurement information for the target MS (e.g. TA 
value). A BSSLAP Reset shall also include the current location area code if there has been any change of location area 
since the location request for the target MS was first sent to the SMLC and if the current location area code was not yet 
reported to the SMLC in a previous BSSLAP Reset. 

8.5.3.5 Priority of Handover and Other RR Management Procedures 

If the transfer of RRLP messages between an SMLC and target MS is interrupted by intra-BSC handover, inter-BSC 
handover or any other intra-BSC RR management procedure, the BSC shall avoid delay to the handover or RR 
management procedure by employing the preemption capability defined in 3GPP TS 44.006 and 3GPP TS 24.008. This 
allows an RR Handover Command or other RR management command sent to the target MS to be assigned a "high" 
priority at the data link level enabling preemption of "low" priority RR Application Information messages (carrying 
RRLP messages) which may have been sent earlier. This procedure ensures that any RRLP data still not transmitted to 
the MS will be preempted (and discarded) by the data link layer in the BTS prior to transmission of the Handover 
Command or other RR Management command. 

8.5.3.6 Interaction with Segmentation support for Legacy MS 

If a location information transfer to an MS initiated by an SMLC is not active, the BSC shall discard any RRLP 
message segment received from the MS. Once a location service procedure has been started involving RRLP message 
transfer to a target MS, the BSC shall discard all RRLP segments received from the MS until it receives the first or only 
segment of a new RRLP message. The new RRLP message shall then be treated according to the state of the RRLP 
message transfer as described in clause 8.L 

Further details regarding transfer and segmentation of RRLP messages between a BSC and MS can be found in 
3GPPTS 44.018. 

8.5.3.7 Overload 

The BSC may indicate an inability to support location due to overload by rejecting with a cause indicating congestion a 
BSSAP Perform Location request received from the MSC. If an SMLC has rejected a request from the BSC to perform 
location with a cause indicating congestion, the BSC shall convey the rejection and cause to the MSC if the request was 
MSC initiated. If the request was initiated by the BSC, the BSC may reduce the frequency of its location requests to the 
SMLC according to the rules in 3GPP TS 49.031, which give precedence to location service requests with a higher 
priority. 
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8.5.4 Procedures in the BSS in tine PS Domain 

8.5.4.1 General Procedures 

The BSS serving a target MS shall supervise any network or MS location service procedure, including transfer of 
positioning assistance data to an MS, and shall only allow one such procedure to be active at any time for any one 
TLLI. If a new procedure is instigated by the SMLC for any target MS, the BSS shall cancel any previous procedure 
without notifying the SMLC or target MS. The new procedure shall then be treated according to the prevailing 
conditions. If a location information transfer to an MS initiated by an SMLC is not active, the BSS shall discard any 
RRLP message received from the MS via the SGSN. 

A serving BSS shall abort all existing location related procedures for a particular target MS without notifying a target 
MS if the SCCP connection to the SMLC is released. In the event of an abort when no BSSLAP procedure is active, but 
a location procedure is active, the BSS shall attempt to notify the SMLC using a BSSAP-LE Perform Location Abort. 

A serving BSS shall abort all existing location related procedures for a particular target MS if the radio connection to 
the MS is lost. The SMLC shall be notified with a BSSAP-LE Perform Location Abort if no BSSLAP procedure is 
currently active. If there is an active BSSLAP procedure, the BSSLAP Abort message shall be sent to the SMLC. 

A serving BSS shall return a BSSLAP Reject to the SMLC containing the cause of rejection, if the BSS receives the 
BSSGP Position Response message from the SGSN indicating a failure. 

8.5.4.2 Rejection of an SMLC Positioning Request 

The BSS may reject any request from an SMLC for positioning or transfer of assistance data for a target MS if the 
request cannot be performed. If the request is rejected, the BSS shall return a BSSLAP Reject to the SMLC containing 
the cause of rejection. 

8.5.4.3 Overload 

The BSS may indicate an inability to support location due to overload by rejecting with a cause indicating congestion 
sent in a BSSGP Perform Location Response message to the SGSN. If an SMLC has rejected a request from the BSS to 
perform location with a cause indicating congestion, the BSS shall convey the rejection and cause to the SGSN if the 
request was initiated by the SGSN. If the request was initiated by the BSS, the BSS may reduce the frequency of its 
location requests to the SMLC according to the rules in 3GPP TS 49.031, which give precedence to location service 
requests with a higher priority. 

8.5.4.4 Inter BSS Cell Change 

If the BSS detects (e.g. when it receives a BSSGP-FLUSH-LL PDU from the SGSN) that a target MS has changed cell 
to another BSS, it shall abort the positioning procedure by sending the BSSAP-LE Perform Location Abort to the 
SMLC. 

8.5.5 Void 

8.6 Procedures in the Target MS 

A target MS shall terminate any positioning procedure or the transfer of RRLP positioning assistance data without 
sending any response to the SMLC if any RR message is received from the BSC that starts some other RR management 
procedure, including a new positioning procedure. The new RR procedure shall then be executed by the MS. 

A target MS shall terminate any positioning procedure or the transfer of RRLP positioning assistance data without 
sending any response to the SMLC if a Routing Area Update Request message is sent to the SGSN or if a suspension 
request message is sent to the network or if its P-TMSI is reallocated. 

8.7 Further Procedures for Handover 

Handover procedures are described in 3GPP TS 23.271 [7]. 



£75/ 



3GPP TS 43.059 version 8.1.0 Release 8 



44 



ETSI TS 143 059 V8.1.0 (2009-01) 



Positioning procedures 



The following clause describes the positioning procedures for Timing Advance, Enhanced Observed Time Difference 
and A-GNSS. 



9.1 Positioning Procedure Initiation 



9.1 .1 Core Network Position Procedure Initiation over the A interface 

This procedure is used by the Core Network to start the positioning procedure in GERAN over the A interface. 
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Figure 26: Positioning Procedure Initiation Over A Interface 

1) The MSC sends the BSSAP Perform Location Request message on the existing SCCP connection for the target 
MS to request the BSC to start the positioning procedure. The Location Type is always included. Depending on 
the type of location request, additional parameters may be included to provide the Cell Identifier, Classmark 
Information Type 3, LCS Client Type, Chosen Channel, LCS Priority, Quality of service, A-GNSS Assistance 
Data, and APDU. In addition, the IMSI and / or the IMEI of the mobile station involved in the positioning 
procedure may be provided by the MSC in order, if forwarded by the BSC, to allow the SMLC to maintain a 
context between subsequent requests for a mobile station, to tune positioning for each mobile station and to add 
more options for SMLC diagnostics. 

2) The common positioning procedures for CS domain are executed (see below). 

3) The BSC sends the BSSAP Perform Location Response message to the MSC. A location estimate, velocity 
estimate, positioning data, deciphering keys, or LCS Cause may be included. 
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9.1 .2 Positioning Procedure Initiation from an Internal LCS Client for the 
CS Domain (A/Gb mode) 

Figure 27 illustrates how a serving BSC may obtain the location of a target MS that is already in dedicated mode on 
behalf of some PLMN operator LCS client in GERAN - e.g. to support handover. The procedure is valid when local 
regulatory requirements do not require privacy checking for PLMN operator initiated location. 
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Figure 27: Positioning Procedure Initiation from an Internal LCS Client 

1) An LCS client within the GERAN requests the current location of a target MS from the serving BSC 

2) The common positioning procedures for CS domain are executed see Figure 28. The BSC returns the MS 
location estimate to the requesting LCS client. 



9.1 .3 Core Network Position Procedure Initiation over the Gb interface 

This procedure is used by the Core Network to start the positioning procedure in GERAN over the Gb interface. 
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Figure 27a: Positioning Procedure Initiation Over Gb Interface 

1) The SGSN sends the BSSGP Perform Location Request message to request the BSS to start the positioning 
procedure. The TLLI, IMSI, DRX Parameters, Current BVCI for the MS, Current NSEI for the MS, Location 
Type, Current Cell Identifier, and LCS Capability lEs are always included. The IMSI, DRX Parameters, 
Current BVCI for the MS, Current NSEI for the MS shall be stored in the SCCP signalling context towards the 
SMLC for potential use in a TA Request procedure later on. Depending on the type of location request, 
additional parameters may be included in the BSSGP Perform Location Request message to provide LCS Client 
Type, LCS Priority, LCS Quality of Service, and A-GNSS Assistance Data. In addition, the IMEI of the mobile 
station involved in the positioning procedure may be provided by the SGSN. The IMSI and, if forwarded by the 
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BSS, the IMEI, would allow the SMLC to maintain a context between subsequent requests for a mobile station, 
to tune positioning for each mobile station and to add more options for SMLC diagnostics. 

2) The common positioning procedures for PS domain are executed (see clause 9.2. 1). 

3) The BSS sends the BSSGP Perform Location Response message to the SGSN. The TLLI and the BVCI 
identifying the cell from which the last LLC PDU was received from the MS are always included. A location 
estimate, velocity estimate, positioning data, deciphering keys, or LCS Cause may be included. 

9.1 .4 Positioning Procedure Initiation from Core Network (lu mode) 

This procedure is used by the Core Network to start the positioning procedure in GERAN lu mode. This procedure is 
used when the source node in the Core Network is the 3G-MSC (lu-cs interface) or when the source node in the Core 
Network is the 3G-SGSN (lu-ps interface). 



MSC/ 




BSC 




SMLC 




MS 


SGSN 
























^ 










1 . Location Reporting 


w 






Control 


2. Positioning Procedure for lu 


mode 




-^ 














3. Lc 


)cation Report 









Figure 27b: Positioning Procedure Initiation from Core Network (lu mode) 

1) The MSC/SGSN sends the Location Reporting Control message on the existing SCCP connection for the 
target MS to request the BSC to start the positioning procedure. The Location Type is always included. 
Depending on the type of location request, additional parameters may be included to provide LCS Client 
Type, LCS Priority, Quality of service, and A-GNSS Assistance Data.. 

2) The Positioning Procedure for lu mode is executed (see below). 

3) The BSC sends the Location Report message to the MSC/SGSN. A location estimate (with optional velocity 
estimate), or LCS Cause may be included. 



9.1.5 

FFS. 



Positioning Procedure Initiation from Internal LCS Client (lu mode) 



9.2 Common Positioning Procedure for CS Domain in A/Gb 
mode 

This procedure is common to all positioning methods in the CS domain. 
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Figure 28: Common Positioning Procedure for CS Domain 

1) The BSC sends the BSSAP-LE Perform Location Request message to request the SMLC to start the positioning 
procedure. The Location Type and Current Cell Identifier IBs are always included. Depending on the type of 
location request, additional parameters may be included to provide Measurement Report (in BSSLAP APDU 
IE), LCS Client Type, Classmark Information Type 3, Chosen Channel, LCS Priority, LCS Quality of Service, 
and A-GNSS Assistance Data. In addition, the IMSI and / or the IMEI of the mobile station involved in the 
positioning procedure may be provided by the BSC in order to allow the SMLC to maintain a context between 
subsequent requests for a mobile station, to tune positioning for each mobile station and to add more options for 
SMLC diagnostics. 

2) If location information is requested and the location accuracy within the QoS, if provided, can be satisfied by the 
reported cell ID and, if available, TA value, the SMLC may send a BSSAP-LE Perform Location Response 
message immediately. Otherwise, the SMLC determines the positioning method and instigates the particular 
message sequence for this method defined in subsequent clauses. If the position method returns position 
measurements, the SMLC uses them to compute a location estimate (with optional velocity estimate). If there 
has been a failure to obtain position measurements, the SMLC may use the current cell ID and, if available, TA 
value to derive an approximate location estimate. If a computed location estimate is returned for an MS based 
position method, the SMLC may verify consistency with the current cell ID and, if available, TA value. If the 
location estimate so obtained does not satisfy the requested accuracy or the location attempt failed, e.g. due to 
missing data, and sufficient response time still remains, the SMLC may instigate a further location attempt using 
the same (e.g. providing more assistance data to MS) or a different position method. If there is insufficient 
response time for another position attempt, the SMLC shall return any location estimate already obtained even if 
not satisfying the requested accuracy. If a vertical location co-ordinate is requested but the SMLC can only 
obtain horizontal co-ordinates, these may be returned. Requirements on the geographic shape encoded within the 
"position information" parameter may exist for certain LCS client types. The SMLC shall comply with any shape 
requirements defined in 3GPP. The SMLC in a certain country should attempt to comply with the shape 
requirements defined for a specific LCS client type in the relevant national standards of that country. If location 
assistance data is requested, the SMLC transfers this data to the MS as described in subsequent clauses. The 
SMLC determines the exact location assistance data to transfer according to the type of data specified by the MS, 
the MS location capabilities and the current cell ID. If deciphering keys are requested the SMLC obtains the 
current keys. 

3) The SMLC sends the BSSAP-LE Perform Location Response message to the BSC containing any location 
estimate (with optional velocity estimate) or deciphering keys. In case of failure the cause value may be 
included. 

9.2a Common Positioning Procedure for PS Domain in A/Gb 
mode 

This procedure is common to all positioning methods in the PS domain. 
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Figure 28a: Common Positioning Procedure for PS Domain 

1) The BSS sends the BSSAP-LE Perform Location Request message to request the SMLC to start the 
positioning procedure. The Location Type, and Current Cell Identifier IBs are always included. If the Timing 
Advance value for the MS is available in the BSS, it shall be included (in BSSLAP APDU IE). Depending on 
the type of location request, additional parameters may be included to provide Measurement Report (in 
BSSLAP APDU IE), Packet Measurement Report, LCS Client Type, LCS Capability, LCS Priority, LCS 
Quality of Service, and A-GNSS Assistance Data. In addition, the IMSI and / or the IMEI of the mobile station 
involved in the positioning procedure may be provided by the BSS in order to allow the SMLC to maintain a 
context between subsequent requests for a mobile station, to tune positioning for each mobile station and to 
add more options for SMLC diagnostics. 

2) See step 2 of clause 9.2 "Common Positioning Procedure for CS Domain in A/Gb mode". 

3) The SMLC sends the BSSAP-LE Perform Location Response message to the BSS. A location estimate, 
velocity estimate, positioning data, deciphering keys, or LCS Cause may be included. 

9.2b Common Positioning Procedure for lu mode 

This procedure is common to all positioning methods in the lu mode. 
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Figure 28b:Common Positioning Procedure 

1. The BSC sends the BSSAP-LE Perform Location Request message to request the SMLC to start the positioning 
procedure. 

2. See step 2 of Clause 9.2 "Common Positioning Procedure for CS Domain in A/Gb Mode." 

3. The SMLC sends the BSSAP-LE Perform Location Response message to the BSC containing any location 
estimate (with optional velocity estimate) or deciphering keys. In case of failure the cause value may be 
included. 
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9.2c GPRS Cell Change for the PS Domain in A/Gb mode 
9.2C.1 Intra-BSS Cell Change 

The procedure shown below is used in order to keep an SMLC updated about Intra-BSS cell changes during a 
positioning procedure for a target MS in the PS domain in A/Gb-mode (note that unlike the CS domain and handover, 
the BSSLAP reset procedure is not used). The following procedure is applicable except when U-TDOA positioning is 
ongoing in the ESS as described in sub-clause 9.5.2.4 of this specification. 
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Figure 28c: Cell Change with BSSAP-LE Perform Location Information for the PS Domain 

1. The MS detects a cell change and sends a cell update message or routing area update message to the SGSN (for 
more information, see 3GPP TS 23.060). 

2. The SGSN sends a BSSGP FLUSH-LL PDU to the BSS. If the cell change is an Inter-NSE Cell Change, the 
NSEI of the new cell is provided. 

3. The BSS acknowledges by sending a BSSGP FLUSH-LL-ACK PDU to the SGSN. 

4. The BSS detects that a positioning procedure is active and the BSS is able to continue the positioning procedure 
in the new cell and sends a BSSAP-LE Perform Location Information message to the SMLC. This message 
contains the Cell Identifier for the new cell. If the Timing Advance value for the MS in the new cell is available 
in the BSS, it shall also be included. The BSS may send this message either if it receives the indication from the 
SGSN about the cell change (the BSSGP FLUSH-LL) or if it detects the cell change on its own (e.g. network 
controlled cell reselection). 

9.20.2 Inter-BSS Cell Change 

The procedure shown below is used to abort the positioning procedure when an Inter-BSS cell change occurs for a 
target MS in the PS domain in A/Gb-mode. The following procedure is applicable except when U-TDOA positioning is 
ongoing in the BSS as described in sub-clause 9.5.2.5 of this specification. 
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Figure 28d: Cell Change with positioning abort for the PS Domain 

1. The MS detects a cell change and sends a cell update message or routing area update message to the SGSN (for 
more information, see 3GPP TS 23.060). 

2. The SGSN sends a BSSGP FLUSH-LL PDU to the BSS. The NSEI of the new cell is provided. 

3. The BSS acknowledges by sending a BSSGP FLUSH-LL-ACK PDU to the SGSN. 

4. The BSS detects that a positioning procedure is active and that the BSS is not able to continue the positioning 
procedure in the new cell (e.g. Inter BSS Cell Change) and sends a BSSAP-LE Perform Location Abort message 
to the SMLC. The IE LCS Cause indicates the reason for the abort (e.g. Inter BSS Cell Change'). The BSS then 
awaits the BSSAP-LE Perform Location Response from the SMLC, which it will forward in a BSSGP Perform 
Location Response to the SGSN. 

9.3 TA Based Positioning in CS Domain for A/Gb-mode 

The TA is based on the existing Timing Advance (TA) parameter. The TA value is known for the serving BTS. To 
obtain TA values in case the MS is in idle mode a special call, not noticed by the GSM subscriber (no ringing tone), is 
set up. The cell-ID of the serving cell and the TA is returned as the result of the TA. 

9.3.1 Definition of TA states 



9.3.1.1 



MS in IDLE State 



In IDLE state the MS may be paged or may request an originating (e.g. emergency) call. The paging response message 
or CM Service Request, in each case respectively, received in COMPLETE_LAYER_3 message may contain location 
information that includes the TA value. If available, the TA value and other location information shall be provided to 
the SMLC by the requesting BSC along with the current serving cell ID in the BSSAP-LE Perform Location request. 
This enables TA based positioning in the SMLC without any further interactions. 



9.3.1.2 



MS in DEDICATED State 



In DEDICATED state the SMLC shall send a TA_REQUEST to request the TA value from the serving BSC. The BSC 
shall respond with either a TA_RESPONSE carrying the TA value and possibly other radio measurements from the MS 
or a Reset. The associated procedure is described in the next clause. 
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9.3.2 TA Positioning Procedure 



This TA positioning procedure is generic for a standalone SMLC or integrate SMLC in the BSC. 
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Figure 29: TA Positioning Procedure for the SIVILC in the OS Domain 

1) The SMLC sends a BSSAP-LE Connection Oriented Information message to the BSC serving a particular target 
MS. The APDU parameter in this message contains a BSSLAP TA Request. 

2) Provided the location area for the target MS has not changed or, if changed, was previously reported to the 
SMLC, the BSC returns the current TA value and current serving cell for the target MS to the SMLC in a 
BSSLAP TA response contained within a BSSAP-LE Connection Oriented Information message. The TA 
response may also include the latest measurement results received from the target MS for the serving and 
neighbouring cells. If the location area for the target MS has changed since the location request was first sent to 
the SMLC and if the new location area has not yet been reported to the SMLC, the BSC shall return a BSSLAP 
Reset to the SMLC within a BSSMAP-LE Connection Oriented Information message. The Reset shall include 
the current serving cell, the current location area code, a cause value indicating 'intra-BSC handover' and the 
current TA value and may include the latest measurement results received from the target MS for the serving and 
neighboring cells. The SMLC then derives a location estimate for the target MS based on the received serving 
cell ID, location area code if included, TA value and other measurement results if included. 

NOTE: In the case of a previous intra-BSC handover to a cell in a different PLMN (different MCC, MNC 

combination), the SMLC would receive a BSSLAP Reset containing the new location area code and new 
cell ID. The SMLC may then deduce the new MCC and MNC from the uniqueness, when this applies, of 
the combined values for the new location area code and cell ID compared to the corresponding values for 
neighbouring cells. 

9.3.3 Unsuccessful TA positioning procedure in BSC 

There are three messages defined to handle error scenarios during positioning procedure in BSC. The messages are 1) 
Reject, 2) Abort and 3) Reset. Refer to 3GPP TS 48.071 [21] for details. 

After receiving the BSSLAP TA Request in BSC, a Reject will be sent with proper cause value from BSC to SMLC in 
"BSSAP-LE Connection Oriented Information Message" if TA positioning cannot be performed in BSC at that time for 
reasons other than handover or another ongoing RR management procedure. 

An Abort or Reset is possible if the TA positioning cannot be done in BSC during that time. Reset is sent to SMLC to 
indicate when the positioning needs to be restarted after temporary interruption due to intra BSC HO or other intra-BSC 
RR management. The contents of a Reset shall be as defined in step 2 in section 9.3.2. Abort is used to indicate to 
SMLC the failure of the current TA positioning attempt (e.g. due to inter-BSC handover) and allowing a new one from 
appUcation level. 

9.3a TA Based Positioning in PS Domain for A/Gb-mode 

The TA is based on the existing Timing Advance (TA) parameter. The TA value is known for the serving BTS. To 
obtain TA values in case the MS is in packet idle mode and the value is not available in the BTS signalling is used to 
retrieve it. The cell-ID of the serving cell and the TA is returned as the result of the TA procedure. 

If available, the TA value shall be provided to the SMLC by the requesting BSS in the BSSAP-LE Perform Location 
request. This enables TA based positioning in the SMLC without any further interactions. The current serving cell ID 
shall always be provided by the BSS to the SMLC. 
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9.3a.1 Definition of PS Domain TA Modes 



9.3a.1.1 



MS in Packet Idle Mode 



When the BSS receives a TA Request message and the MS is in Packet Idle Mode and the TA value is not available in 
the BSS, the MS may be paged or may be sent a Packet Polling Request message. If there is a PBCCH allocated in the 
current cell, the BSS will send a Packet Polling Request message to the MS. If there is no PBCCH allocated in the 
current cell, the BSS will perform packet paging (sends a Paging Request Type 1, 2, or 3 message) for the MS. 

The paging response message or Packet Control Acknowledgement message will provide the TA value to the BSS and 
this will be provided to the SMLC, possibly together with other radio measurements from the MS, in the TA Response 
message. The associated procedure is described below. 



9.3a.1.2 



MS in Packet Transfer Mode 



When the BSS receives a TA Request message and the MS is in Packet Transfer Mode and the TA value is not 
available in the BSS the MS shall be sent a Packet Polling Request message to the MS. 

The Packet Control Acknowledgement message will provide the TA value to the BSS and it will be provided to the 
SMLC, possibly together with other radio measurements from the MS, in the TA Response message. The associated 
procedure is described in the next clause. 

9.3a.2 TA Positioning Procedure 

This TA positioning procedure is generic for a standalone SMLC or integrate SMLC in the BSS. 
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Figure 29a: TA Positioning Procedure for the SIVILC in the PS Domain 

1) If the SMLC has not already received the TA Value in the BSSAP-LE Perform Location Request message, the 
SMLC sends a BSSAP-LE Connection Oriented Information message to the BSS serving a particular target 
MS. The APDU parameter in this message contains a BSSLAP TA Request. 

2) If the TA value is available in the BSS, the BSS immediately returns it in step 4, otherwise the BSS either 
performs a packet paging procedure or sends a Packet Polling Request message (for details, see clause 9.5.1). 

2a) If there is no PBCCH allocated in the current cell and the MS is in Packet Idle Mode, the BSS will perform 
packet paging (sends a Paging Request Type 1, 2, or 3 message) for the MS. 

2b) If there is a PBCCH allocated in the current cell or the MS is in Packet Transfer Mode, the BSS will send 
a Packet Polling Request message to the MS. 

3) The MS responds to the BSS. 

3a) If the MS receives the packet paging it will send a page response. 
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3b) If the MS receives a Packet Polling Request message it will return a Packet Control Acknowledgement 

message. 

4) The BSS returns the current TA value and current serving cell for the target MS to the SMLC in a BSSLAP TA 
response contained within a BSSAP-LE Connection Oriented Information message. The TA response may also 
include the latest measurement results received from the target MS for the serving and neighbouring cells. The 
SMLC then derives a location estimate for the target MS based on the received serving cell ID, TA value and 
other measurement results if included. 

9.3a.3 Unsuccessful TA positioning procedure in BSS 

There are three messages defined to handle error scenarios during positioning procedure in BSS. The messages are 1) 
Reject, 2) Abort and 3) Reset. Refer to 3GPP TS 48.071 [21] for details. The Reset message does not apply for PS 
domain. 

After receiving the BSSLAP TA Request in BSS, a Reject will be sent with proper cause value from BSS to SMLC in 
"BSSAP-LE Connection Oriented Information Message" if TA positioning cannot be performed in BSS at that time for 
reasons other than handover or another ongoing RR management procedure. 

An Abort is possible if the TA positioning cannot be done in the BSS during that time. Abort is used to indicate to 
SMLC the failure of the current TA positioning attempt (e.g. due to reception of an BSSGP_Perform_Location_Abort 
from the SGSN) and allowing a new one from application level. 

9.4 E-OTD and A-GNSS Positioning Procedures 

9.4.1 General procedures 

For any location request where the highest priority level is assigned and MS-based A-GNSS positioning is not used, the 
SMLC functionality shall provide sufficient assistance data to a target MS to enable a location estimate, velocity 
estimate, or location measurements to succeed according to the required QoS on the first attempt. The SMLC shall not 
assume in this case that the target MS already possesses assistance data. For a lower priority location request or when 
MS-based A-GNSS positioning is used, the SMLC may reduce the assistance data provided to a target MS on the first 
location attempt. 

In the high priority case with MS-assisted GNSS for the first positioning attempt, acquisition assistance data shall be 
included in the RRLP measure position request message. 

9.4.2 Positioning Request 

This signaling flow is generic for all MS based or assisted location methods (MS Based E-OTD, MS Assisted E-OTD, 
MS Based A-GNSS, and MS Assisted A-GNSS). The signaling flow below appHes to integrated and standalone SMLCs 
in a circuit switched network. 

If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation, see clause 6.1.2, and transfer the LCS 
assistance data more reliably, this procedure may be preceded by an "Assistance Data Delivery" procedure. Note, that 
part of the entire set of assistance data may be included in the RRLP Measure Position Request even when the message 
is preceded by an "Assistance Data Delivery" procedure. 

If the MS has indicated support for providing MS positioning capabilities using RRLP in the MS Classmark 3 IE for 
GSM (see 3GPP TS 24.008), in the PS LCS CapabiHty IE for GERAN Gb mode (see 3GPP TS 24.008), or in the MS 
Positioning Capability IE for GERAN lu mode (see 3GPP TS 44. 1 18), this procedure may be preceded by a 'Positioning 
Capability Transfer' procedure. 
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Figure 30: E-OTD or A-GNSS Position Request Flow 

1) The SMLC may precede the RRLP MEASURE POSITION REQUEST or Assistance Data Delivery procedure 
with a Position Capability Transfer procedure, if the MS supports the transfer of MS positioning capabilities 
using RRLP. 

2) The SMLC may precede the RRLP MEASURE POSITION REQUEST with an optional Assistance Data 
Delivery procedure. 

3) The SMLC determines possible assistance data and sends RRLP MEASURE POSITION REQUEST to the BSC. 

4) The BSC forwards the positioning request including the QoS and any assistance data to the MS in a RRLP 
MEASURE POSITION REQUEST. 

5) The MS performs the requested E-OTD or GNSS measurements, if needed assistance data is available in the MS. 
If the MS is able to calculate its own location and this is required and needed assistance data is available in MS, 
the MS computes a location estimate based on E-OTD or GNSS measurements. In case of E-OTD, any data 
necessary to perform these operations will either be provided in the RRLP MEASURE POSITION REQUEST or 
available from broadcast sources. In case of A-GNSS (both MS based and MS assisted) and first positioning 
attempt, a minimum set of A-GNSS assistance data will be either provided in the RRLP MEASURE POSITION 
REQUEST or available from broadcast sources. For further positioning attempt (failure in first attempt due to 
missing assistance data), sufficient A-GNSS assistance data, possibly excluding the assistance data sent in the 
first attempt, will be provided in the RRLP MEASURE POSITION REQUEST and possibly preceding RRLP 
ASSISTANCE DATA messages. The resulting E-OTD or GNSS measurements or E-OTD or GNSS location 
estimate (with optional velocity estimate) are returned to the BSC in a RRLP MEASURE POSITION 
RESPONSE. If the MS was unable to perform the necessary measurements, or compute a location, a failure 
indication identifying the reason for failure (e.g. missing assistance data) is returned instead. In case of A-GNSS, 
if the MS was unable to compute a location, the GNSS measurements are also optionally returned if allowed by 
the network. If the RRLP message is larger than the RRLP maximum PDU size, several RRLP MEASURE 
POSITION RESPONSE messages are sent (i.e. the RRLP pseudo-segmentation is used). 

6) BSC forwards the RRLP MEASURE POSITION response to SMLC. 

9.4.3 Assistance Data Delivery 

This signalUng flow is generic for MS Based and MS Assisted E-OTD, and MS Based or MS Assisted A-GNSS in a 
circuit switched network. 

If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation and transfer the LCS assistance data more 
reliably, the sequence 1 -4 illustrated in the figure below may be repeated several times to deliver more assistance data 
than can be sent by one RRLP Assistance Data Delivery message. In this case, each individual message is independent 
such that the data received in one message is stored in the MS independently of the other RRLP Assistance Data 
messages (i.e. an error of delivery of one message does not require a retransmission of all the RRLP Assistance Data 
messages). The SMLC shall indicate in the RRLP ASSISTANCE DATA message if more RRLP ASSISTANCE DATA 
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messages will be used after the current one in order to deliver the entire set of assistance data. Data that is specific to the 
current cell should be sent in the last message this is recommended so that assistance data for the correct cell is 
available to the MS after a handover. 



SMLC 



BSC 



1 . RRLP Assistance Data 



4. RRLP Assistance Data Acl<. 



MS 



2. RRLP Assistance Data 



3. RRLP Assistance Data Acl<. 



Figure 31 : E-OTD or A-GNSS Assistance Data Delivery Flow 

1) The SMLC determines assistance data and sends it in the RRLP ASSISTANCE DATA message to the BSC. 

2) The BSC forwards the assistance data to the MS in a RRLP ASSISTANCE DATA message. 

3) The MS acknowledges the reception of complete assistance data to the BSC with a RRLP ASSISTANCE DATA 
Ack. 

4) The BSC forwards the RRLP ASSISTANCE DATA Ack message to the SMLC. 



9.4.3a Positioning Capability Transfer 



The purpose of this procedure is to enable the SMLC to obtain the positioning capabilities of the MS, the types of 
assistance supported and the types of assistance data that may be needed from the SMLC. MS support for this procedure 
can be indicated to the SMLC using the MS Classmark 3 IE for GSM (see 3GPP TS 24.008), the PS LCS Capability IE 
for GERAN Gb mode (see 3GPP TS 24.008) and the MS Positioning Capability IE for GERAN lu mode (see 3GPP TS 
44.118). 



SMLC 



BSC 



RRLP Position Capability Request 



RRLP Position Capability Response 



MS 



RRLP Position Capability Request 



RRLP Position Capability Respo 



nse 



Figure 31a: RRLP Position Capability Transfer Flow 

1) The SMLC determines that the target MS supports MS Positioning Capability Transfer using RRLP and sends a 
Positioning Capability Request message to the BSC. 
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2) The BSC forwards the Positioning CapabiUty Request message to the MS. 

3) The MS sends the Positioning Capability Response message to the BSC. The response message shall include the 
positioning capabilities of the MS and the types of supported assistance data (if applicable). The message may 
include the types of assistance needed by the MS to obtain a location estimate or positioning measurements. 

4) The BSC forwards the Positioning Capability Response message to the SMLC. 



9.4.4 Error Handling for E-OTD and A-GNSS in CS Domain 

This clause describes error handling for positioning and transfer of assistance data for E-OTD and A-GNSS. For a 
description of error handling involving segmentation, and more details on usage of a BSSLAP Abort, Reject and Reset 
refer to clause 8.5 Exception Procedures. 

Case 1 : When the RRLP request comes to BSC for E-OTD and A-GNSS, The BSC will send a BSSLAP reject 
message to SMLC if the request cannot be supported in the BSC for reasons other than an ongoing intra 
BSC or inter BSC handover or other ongoing RR management procedure. For an ongoing intra BSC HO 
or other RR management procedure, the BSC shall return a BSSLAP Reset when the handover or RR 
management procedure is complete. The SMLC may then start the RRLP request (if there is time) again. 
For ongoing inter-BSC HO, the BSC shall return a BSSLAP Abort. The location service request may then 
restart from the LCS CHent, VMSC or SGSN. 

Case 2: When the RRLP request comes to BSC from SMLC, BSC sends the "RRLP request" to the MS if there is 
no ongoing HO or other RR management procedure at that point. If an intra-BSC HO or other RR 
management procedure is initiated in BSC, the BSC sends the HO or other RR management command to 
MS. A timer will then be started in BSC, the duration of which is network dependent, but typically 6 (six) 
seconds. Upon receiving the HO of other RR management command, the MS will stop the location 
procedure and start on handover or other RR management procedure, since this has higher priority than 
location. The MS will then send the HO complete or other RR management response message to BSC. 
When this message is received before the expiration of BSC timer, a BSSLAP Reset message will be sent 
to SMLC from BSC. The Reset will tell SMLC to start another location service request if there is enough 
time. 

Case 3: During intra-BSC HO or other intra-BSC RR management procedure, if a HO complete or RR 

management procedure completion was not received in BSC and the corresponding timer expired. In this 
case a reset or abort message will be sent to SMLC indicating MS timeout. The location service may then 
restart from either the SMLC if a reset was sent or from the LCS Client, VMSC or SGSN if an abort was 
sent. 

Case 4: If an inter-BSC handover is needed during a location procedure or if the BSC times out on an RRLP 
response from the target MS, the BSC shall send a BSSLAP Abort to the SMLC. The location service 
attempt may then be restarted from the LCS Client, VMSC, or SGSN. 
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9.4.5 Error Handling for the SMLC in CS Domain 



SIVLC 



BSC 



1. RRLP Request 



2. Rejector Reset or Abort (Case 1 ) 



OR 
Intra-BSC Hardover Initiated, T3103 started X 

Handover attempt cxDmpleted 
5. Reset (Case 2) 



4. HO Complete 

N 



OR 



5'. Reset or Abort (Case 3) 



OR 



5'. Abort (Case 4) 



MS 



Z. RRLP Request 



3. HOCorrmand 



OR 



. T31 03 Expired, HO cx)mplete ntDt received 
OR 



Inter-BSC handover required or 
timeout on an RRLP response 



from 



BSC 
thelVIS 



Figure 32: Error Handling for the SMLC In the CS Domain 

9.4.5a Error Handling for E-OTD and A-GNSS in PS Domain 

Case 1 : When the RRLP request comes to BSS for E-OTD and A-GNSS, the BSS will send a BSSLAP reject 
message to SMLC if the request cannot be supported in the BSS. 

Case 2: When the RRLP request comes to BSS from SMLC, BSS sends the "RRLP request" to the MS via the 
SGSN and starts position supervision timer. After this, if the BSS determines that the current location 
procedure cannot be continued, the BSS sends an abort message to the SMLC. Notice that an MS 
reselection to a new cell is not a reason for the BSS to abort the procedure. 

Case 3: If the position supervision timer times out in BSS before the RRLP response from the target MS is 

received, the BSS shall send a BSSLAP Abort to the SMLC. The location service attempt may then be 
restarted from the LCS Client, VMSC, or SGSN. 
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SGSN 



2. RRLP Request 



RRLP Response 



Position supervision 
timer expired 



MS 



3. RRLP Request 



RRLP Response 



Figure 32a: Error Handling for the SMLC in PS domain 

9.4.6 Broadcast of Assistance Data 

In MS Based E-OTD, MS Based GPS and MS Assisted A-GNSS systems, there may be a need for assistance data to be 
broadcast to the MS. The assistance data to be broadcast for MS Based E-OTD contains the Real Time Difference 
(RTD) values (in case of a non-synchronised network) and Base Transceiver Station (BTS) coordinates. In addition, the 
broadcast data contains other information simplifying the E-OTD measurements. The broadcast of A-GNSS assistance 
data may make available the same information as in A-GNSS point-to-point signalling. It improves the location 
accuracy for MS Based implementations, increases the sensitivity, enables LMU-independent time dissemination and 
assists the acquisition of satellite signals for both MS Based and MS Assisted implementations. 

The CS mechanism (Cell Broadcast on CBCH) is used for broadcast of assistance data for all MSs, irrespective of 
which domain (CS or PS) they are located in. Notice that it may take longer for an MS in the PS domain compared to 
the CS domain to read all the broadcast data. This is because the PBCCH is not co-ordinated with the CBCH and 
therefore, the MS may have to skip reading a CBCH slot in order to listen for a potential paging message. 

The E-OTD assistance data to be broadcast is in compressed format where the redundant information is not included. 
The MS is capable to reconstruct the E-OTD assistance data using the message header information. The length of the 
message is depending on how many neighbours are included in the E-OTD assistance data as well as whether the 
redundant information can be removed from the message. The typical size of one broadcast message will be less than 82 
octets. Part of the broadcast message (serving and neighbour base station coordinates) may be ciphered. 

The contents of the broadcast message for the E-OTD and A-GNSS assistance data is described in 3GPP TS 44.035 
[16]. The support for these broadcast messages is optional for network and MS. 

The broadcast channel which is used to broadcast the E-OTD and A-GNSS assistance data make use of the existing 
basic or extended CBCH and SMSCB DRX service. The LCS broadcast messages need to be either scheduled, or 
prioritised over other broadcast messages to avoid any delay. 



9.4.6.1 



Point-To-Multipoint Assistance Data Broadcast Flow 



This signalHng flow is generic for MS Based E-OTD, MS Based A-GNSS and MS Assisted A-GNSS methods. The E- 
OTD/ A-GNSS Assistance Data Broadcast Message is created in SMLC and the whole message including the ciphered 
parts and parameters to control the transfer are transferred with below flow from SMLC to MS. SMSCB DRX service 
is used for LCS assistance data broadcast. Prior receiving the first schedule message MS should read first block of each 
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message lot to be able to receive the LCS Broadcast Data or the schedule message. After receiving the schedule 
message MS should receive the LCS Broadcast Data messages according the schedule information. 



CBC 



SMLC 



1 . LCS Broadcast Data(dat i & parameters) 



BSC 



BTS 



MS 



2. SMSCB messages between CBC - BSC - BTS described in 3GPP TS 23.041 



3. LCS Broadcast Data Response 



4. LCS Broadcast Data(data) 
message from BTS to IVIS 
described in 3GPP TS 23.041 



Figure 33: E-OTD/A-GNSS Broadcast Data Flow 

1) SMLC sends the complete broadcast message to CBC with LCS Broadcast Data message. This LCS Broadcast 
Data message contains the data to be broadcasted as well as parameters that indicate to which BTS the broadcast 
message is targeted and what time the broadcast should happen. LCS Broadcast Data (data & parameters) 
message may also contain the SMSCB scheduling information which can be utilised for the SMSCB DRX 
feature specified in 3GPP TS 44.012 [13] specification. SMSCB DRX operation is required in order that MS 
performance can be optimised. 

2) CBC starts message transfer to BSC and BTS according to 3GPP TS 23.041 [6]. 

3) LCS Broadcast Data Response message from CBC to SMLC is used to indicate that the LCS Broadcast Data has 
been delivery request has been fulfilled. This message is not mandatory 

4) BTS starts the message transfer to MS according to 3GPP TS 23.041 [6]. 
Implementations that have SMLC and/or CBC integrated into BSC may use other message signalling. 



9.4.6.2 



Ciphering 



In order for the operators to control the access to the assistance data, parts of the broadcast data may be ciphered. 
Ciphering is done with a specific key delivered by the network for this purpose. The deciphering keys may be requested 
by the MS as described in 3GPP TS 23.271 [7]. The LCS Broadcast Data, when ciphered, will be partially ciphered 
according to the LCS broadcast message definitions specified in 3GPP TS 44.035 [16]. The parts that will be ciphered 
in E-OTD LCS Broadcast Data message are neighbour RTD values, serving and neighbour BTS coordinates. For A- 
GNSS, all assistance data may be ciphered. The MS is capable to decipher the broadcast message (ciphered parts) using 
the cipher key (56 bits) delivered from the Core Network to MS and using the Ciphering Serial Number (16 bits) 
included in the broadcast message. 



9.4.6.2.1 



Algorithm 



The algorithm used for ciphering is the standard 56-bit DES algorithm. The deciphering of broadcast messages is done 
in the MS. SMLC ciphers the LCS Broadcast Data message (part of message is ciphered) using the deciphering keys 
(56 bits) and Ciphering Serial Number (16 bits) included in broadcast message using 56-bit DES algorithm. 

The ciphered part is variable length with one bit resolution. From LCS Broadcast Data message header MS can compute 
what part of message is ciphered. 

Inputs to the 56-bit DES algorithm are the following: 
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56-bit key K (deciphering key); 

16-bit Ciphering Serial Number from broadcast message which is denoted here by IV (initialisation vector); 

plaintext bits (the ciphered part of broadcast message). 

Encryption is done by producing a mask bit stream which is then added bit-by-bit to the plaintext data (XOR-operation) 
to obtain the cipher text data. First IV is concatenated with 0-bits in order to achieve a 64-bit block li. This block is then 
encrypted by the DBS algorithm using the key K. Output is a 64-bit block I2. This constitutes the first 64 bits of the 
mask bit stream. If the message is longer than 64 bits, then more bits are needed. Those are produced by encrypting I2 
again by the DBS algorithm using the key K. Output is a 64-bit block I3. This constitutes the next 64 bits of the mask bit 
stream. This iteration is continued until enough bits are produced. The unnecessary bits from the last 64-bit block Ij are 
discarded. Below figure describes the first two mask bit generations and the two ciphered 64-bit blocks. 




Figure 34 : Ciphering Algorithim 

Decryption is done similarly. The same mask bit stream is produced. This time the mask stream bits are added bit-by-bit 
(XORed) to the ciphertext data bits. The result will be the plain text data. 



9.4.6.3 



Deciphering key control and delivery to MS 



The deciphering keys are needed in MS if the LCS Broadcast Data (ciphered parts) is ciphered. The deciphering keys' 
control system contains two keys (the Current Deciphering Key and the Next Deciphering Key) and the Ciphering Key 
Flag (indicating the current Ciphering Key Flag state in the location area in the time that the deciphering key set is 
delivered from SMLC to MS). Two Deciphering Keys are needed in order to overcome the problem of unsynchronised 
nature of the periodic location updates that MSs make in the location area. The SMLC controls the keys and there are 
following requirements related to the deciphering keys: 

Deciphering Key Set (Current and Next Deciphering Key, Ciphering Key Flag) are always location area specific. 

One SMLC controls the deciphering key set changes inside the location area and in case several SMLCs in the 
location area then one coordinating SMLC for the deciphering key set control must be nominated. The SMLC 
configuration is done with O&M procedures. 
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The coordinating SMLC delivers the new deciphering key set to the other SMLCs with SMLCPP protocol when 
the deciphering key set changes. The Ciphering Key Flag in the LCS Broadcast Data message is changed only 
when the coordinating SMLC changes the deciphering key set and delivers the new set to other SMLCs in the 
same location area. 

The SMLCs upon receiving the new deciphering key set, start using immediately the new set in the LCS 
Broadcast Data message. The coordinating SMLC also starts using the new set same time. 

The deciphering key set changes always following way when the new set is generated: 

The Next Deciphering Key comes to the Current Deciphering Key in the new set. 

One new key is taken into use and named as the Next Deciphering Key. 

The Ciphering Key Flag changes the state. 
The Ciphering Key Flag controls the MS key usage (Current/Next Deciphering Key) as follows: 

After receiving the new deciphering key set, MS starts using the new set immediately. 

The Ciphering Key Flag in the LCS Broadcast Data message and the one received returned to the MS should 
have same polarity. This means that MS starts using the Current Deciphering Key immediately. 

When the Ciphering Key Flag state changes in the LCS Broadcast Data message then MS starts to use the Next 
Deciphering Key for deciphering the broadcast message. The Next Deciphering Key becomes now the Current 
Deciphering Key in MS. 

Figure 35 describes the deciphering key delivery mechanism. 
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Figure 35: Deciphering key delivery 

First the key A is the Current Deciphering Key and key B is the Next Deciphering Key. 

When the SMLC changes to use the key B (Next Deciphering Key) then the Deciphering Key Flag state is 
changed in the LCS Broadcast Data message. At this point the coordinating SMLC delivers the new deciphering 
key set to other SMLCs in the same location area as well as to MS when MS is requesting the keys during the 
location update (IMSI Attach, Normal or Periodic Location Update). 

The new deciphering key set contains now key B as the Current Deciphering Key, key C as new Next 
Deciphering Key and the Ciphering Key Flag currently in use in that location area. 
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When the SMLC changes to use the key C (Next Deciphering Key) then the Ciphering Key Flag state is changed 
in the LCS Broadcast Data message. At this point the coordinating SMLC deHvers the new deciphering key set 
to other SMLCs in same location area as well as to MS when MS is requesting the new set during the location 
update (IMSI Attach, Normal or Periodic Location Update). 

The new deciphering key set contains now key C as the Current Deciphering Key, key D as new Next 
Deciphering Key and the Ciphering Key Flag currently in use in that location area. 

The process continues as above when the keys are changed. The lifetime of one key (Current/Next Ciphering Key) is 
minimum one periodic location update period used in the location area. 

9.5 U-TDOA Positioning Procedures 

9.5.0 General 

Following the receipt of a location request message from the BSC, the U-TDOA capable SMLC interrogates the BSS 
for the RF channel information associated with the MS to be located. The SMLC uses this information to task the 
LMUs at the serving and surrounding cells. The LMUs are tasked to measure the identified RF channel(s) and thus 
provide a time reference from different LMUs. The time-of-arrival information from the tasked LMUs is returned to the 
SMLC where the MS location is calculated. 

9.5.1 U-TDOA Positioning in CS Domain for A/Gb-mode 



9.5.1.1 



General Procedures 



The U-TDOA location method uses the uplink energy transmitted by an MS to make a location determination. If the 
MS was in the dedicated mode, carrying subscriber traffic prior to the beginning of the location process, the energy 
associated with this subscriber traffic can be used to locate the MS. If the MS was placed in the dedicated mode by the 
MSC specifically for location determination purposes, either the SDCCH or TCH can be used for U-TDOA location 
purposes. 

9.5.1 .2 CS U-TDOA Messages and Procedures on the Lb Interface 

The following section describes the positioning procedure for CS U-TDOA location determination on the Lb interface. 



SMLC 



BSC 



1.) BSSLAP U-TDOA Request 



2.) BSSLAP U-TDOA Response 



3.) BSC initiates power-up 
procedures 



Figure 36: CS U-TDOA Positioning Procedure 

I. The SMLC sends a BSSMAP-LE Connection Oriented Information message to the BSC that contains the 
embedded BSSLAP U-TDOA Request message. The U-TDOA Request message may contain the delta timer 
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value. The BSC starts the deha timer, received or internal, immediately after sending the U-TDOA Response 
message to the SMLC. The purpose of this timer is to define the maximum time during which the BSC 
supervises the location request. 

2. The BSC sends a BSSMAP-LE Connection Oriented Information message to the SMLC that contains the 
embedded BSSLAP U-TDOA Response message. The U-TDOA Response message contains the physical 
channel information (frequencies, hopping sequence, channel type, time slot, sub-channel number, etc.), the 
intended Power-Up Starting Time (if the power-up procedure for U-TDOA is supported), the MS power, the 
cell identifier, and the TA. If frequency hopping is used, the U-TDOA Response message also includes the 
frequency list. The U-TDOA Response message also contains the ciphering key (Kc) if ciphering is used on the 
air interface and the version of the applied A5 ciphering algorithm (A5/x). The Kc is ciphered if sent from the 
SMLC to any LMU. The SMLC and any LMU with which it interacts shall also be mutually authenticated. 
These requirements shall be met using a security mechanism meeting the capabilities of the Zb interface of 
NDS/IP (TS 33.210) or TLS (RFC 2246). The LMU installation shall meet the same physical security 
requirements as a BTS installation. For locations on channels that are not ciphered, the algorithm identifier will 
show the same. 

3. If the power-up procedure for U-TDOA is supported, the BSC may use the normal power-control command to 
order the MS to go to the maximum power allowed by the BTS. After the MS has been at full power for a 
period of one second, the BSC shall return to normal power-control. During the time the MS is ordered to the 
maximum power, the BSC may temporarily suspend uplink DTX, if in use. 



9.5.1.3 



RR Procedure effecting the CS U-TDOA channel description 



The location determination process is not an instantaneous event and it can take a few seconds to collect and calculate 
location determination related data. If changes happen to the last reported channel description and the location 
determination is not complete, an updated channel description needs to be sent to the SMLC. 

The BSC considers the location determinations complete if; it receives a BSSAP-LE Perform Location response 
message; or the delta timer expires; or it receives a valid BSSLAP message for a new positioning method. 

The RR procedures that effect the U-TDOA channel description are listed in Table 9.5.1. The 'Treatment' column lists 
the appropriate BSSLAP message to be sent by the BSC to the SMLC. The Reset message is defined in 3GPP TS 
48.071 and shall contain the updated channel description. After sending the Reset message the BSC shall restart the 
delta timer and continue supervision of the location request. 

Table 9.5.1 : RR Procedures affecting the CS U-TDOA channel description 



RR Procedure in Dedicated Mode 


Treatment 


Comments 


Channel assignment procedure. 


Reset 




Handover procedures (intra-BSS). 


Reset 


For successful intra-BSS handover. 


Frequency redefinition procedure. 


Reset 


Only meaningful in the case of frequency hopping. 


Packet request procedure while in 
dedicated mode. 


Reset 


For DTM, when an existing CS connection is 
modified as PS resources are added in order to 
comply with MS frequency/time domain 
restrictions. 


Packet downlink assignment while 
in dedicated mode 


Reset 


For DTM, when an existing CS connection is 
modified as PS resources are added in order to 
comply with MS frequency/time domain 
restrictions. 


Channel mode modify 


Reset 





If the BSC receives the BSSLAP U-TDOA Request message during one of the identified RR procedures in Table 9.5.1, 
it will complete the ongoing RR procedure and then respond with the BSSLAP U-TDOA Response message. 
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9.5.1.4 



BSC Error Handling during CS U-TDOA Positioning Procedure 



There are three (3) BSSLAP messages defined to handle error scenarios that occur during the U-TDOA location 
process: Reset, Reject and Abort. Please refer to 3GPP TS 48.071 for the messages" details. The BSSLAP Reset 
message is used to update the U-TDOA channel description as outlined in 9.5.1.3. 

In Table 9.5.2, all identified RR procedures are listed that result in the BSSLAP Abort message to be sent from the BSC 
to the SMLC. The Abort message is only sent if the U-TDOA location determination is not complete. The BSC 
considers the location determinations complete if; it receives a BSSAP-LE Perform Location response message; or the 
delta timer expires; or it receives a valid BSSLAP message for a new positioning method. 

Table 9.5.2: RR Procedures resulting in BSC Error Handling 



RR Procedure in Dedicated Mode 


Treatment 


Handover procedure (inter-BSS). 


Abort 


Handover to UTRAN procedure. 


Abort 


Handover to CDMA2000 procedure. 


Abort 


RR connection release procedure. 


Abort 



If the BSC receives the BSSLAP U-TDOA Request message during one of the identified RR procedures in Table 9.5.2, 
it will respond with the BSSLAP Abort message. 

If the BSC is unable to perform the U-TDOA positioning for other reasons than those related to the items listed in Table 
9.5.1 and Table 9.5.2, it will respond to the BSSLAP U-TDOA Request message with the BSSLAP Reject message. 

9.5.2 U-TDOA Positioning in PS Domain for A/Gb-mode 



9.5.2.1 



introduction 



The U-TDOA location method uses information transmitted by an MS to make a location determination. The initial 
state of the MS will be identified and will dictate the procedure to be followed in the location process. If the MS was in 
the packet transfer mode, sending uplink RLC/MAC blocks prior to the beginning of the location process, the energy 
associated with this continuing uplink data can be used to locate the MS. If the MS was previously idle in the uplink 
direction and placed in the active state by the SGSN specifically for U-TDOA location determination purposes, it is 
necessary to cause the MS to send uplink information using the Packet polling procedure (see 3GPP TS 44.060). 

An uplink block of data containing the PACKET CONTROL ACKNOWLEDGEMENT message is equivalent to any 
other RLC/MAC block for U-TDOA location purposes; i.e. one uplink RLC/MAC block is equivalent to one execution 
of the Packet polling procedure. This applies only to the lowest numbered timeslot in the case of a multi-slot uplink 
TBF. The Polling Repetition information element in the U-TDOA Request message defines the total number of 
RLC/MAC uplink blocks required to achieve the desired location QoS within a recommended period of two seconds, 
including any PACKET CONTROL ACKNOWLEDGEMENT message received due to the execution of a Packet 
polling procedure. 



9.5.2.2 



General Procedures 



The U-TDOA location method procedures depend on the initial condition of the MS. If the MS is initially in packet 
idle mode the Packet Polling method shall be applied as described in sub-clause 9.5.2.2.1. When the MS is initially in 
the packet transfer mode it may or may not be sending uplink data. If the MS is not sending uplink data the Packet 
polling procedure shall be applied. The application of the U-TDOA location method in the packet transfer mode is 
described in sub-clause 9.5.2.2.2. 
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9.5.2.2.1 MS in packet idle mode 

For an MS that is in packet idle mode, application of the U-TDOA location method requires that a single timeslot 
downlink TBF be established. This downlink TBF shall be used for repeated executions of the Packet polling procedure 
in order to cause a mobile to transmit for a time sufficient to achieve the requested level of location accuracy. The 
number of repetitions of the Packet polling procedure required to achieve the desired level of accuracy shall be 
indicated in the U-TDOA REQUEST message sent from the SMLC to the BSS. 

The BSS shall execute the indicated number of Packet polling procedures after an implementation dependent interval to 
allow assignment of the Location Measurement Units (LMU) to the indicated ARFCN and timeslot(s). The RRBP field 
shall be used to schedule the resulting PACKET CONTROL ACKNOWLEDGEMENT messages. The BSS must 
indicate a PACKET CONTROL ACKNOWLEDGEMENT response containing the TLLI by setting the TYPE OF 
ACK information element to RLC/MAC control block in all PACKET POLLING REQUEST messages associated with 
U-TDOA positioning. 

If the MS is allocated an uplink TBF prior to completion of the required number of Packet polling procedures, the BSS 
may suspend the Packet polling procedure and send a Reset message to the SMLC containing the physical channel 
information for the allocated uplink TBF. Following sending of a Reset message, the BSS shall reset the Polling 
Repetition counter to zero and restart the U-TDOA positioning procedure after an implementation dependent interval. 

The downlink TBF established for U-TDOA location purposes should be used if a single timeslot downlink TBF is 
required during the execution of the U-TDOA location procedure. If a multi-slot downlink TBF is required during the 
execution of the U-TDOA location procedure, the assignment of this TBF may be delayed until the completion of the 
U-TDOA location procedure, otherwise the BSS shall send a Reset message to the SMLC and reset the Polling 
Repetition counter as described previously. 

If both an uplink TBF and a downlink TBF are required during the execution of the U-TDOA location procedure, the 
Packet polling procedure may be restarted and the uplink RLC/MAC blocks can be used for U-TDOA location as 
described subsequently. 

9.5.2.2.2 MS in packet transfer mode 

If only a downlink TBF exists it shall be used to execute the Packet polling procedure, on the lowest numbered timeslot 
transmitted before the last PACKET POLLING REQUEST/PACKET CONTROL ACKNOWLEDGEMENT cycle has 
been completed, the BSS shall not set the FBI bit in the RLC/MAC header of the last data block. The TBF shall be 
terminated after the last cycle of the Packet polling procedure using a PACKET TBF RELEASE message from the BSS. 
If the MS is allocated an uplink TBF prior to completion of the required number of Packet polling procedures, the BSS 
may suspend the Packet polling procedure and send a Reset message to the SMLC as described in sub-clause 9.5.2.2.1. 

If only an uplink TBF exists and RLC/MAC blocks are available for transmission (on the lowest numbered timeslot for 
a multi-slot TBF), those blocks shall be used to locate the MS using the U-TDOA location method. If the number of 
uplink blocks pertaining to the uplink TBF is insufficient to satisfy the requested number of uplink data blocks within 
an implementation dependent period recommended to be two seconds, the Packet polling procedure shall be executed 
on the existing uplink TBF for the balance of the requested blocks. The lowest numbered timeslot shall be used for the 
Packet polling procedure if the existing uplink TBF is a multi-slot TBF. The uplink TBF shall not be terminated until 
the Packet polling procedures have been completed. 

If both an uplink and downlink TBF exist, either TBF may be used for MS location using the U-TDOA location method 
as described previously. The TBF should not be terminated until the Packet polling procedures have been completed. 

9.5.2.3 PS U-TDOA Messages and Procedures on the Lb Interface 

The following section describes the positioning procedure for PS U-TDOA location determination on the Lb interface. 
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1.)BSSLAP U-TDOA Request 
2.) BSSLAP U-TDOA Response 



Figure 37: PS U-TDOA Positioning Procedure 

1. The SMLC sends a BSSMAP-LE Connection Oriented Information message to the BSS that contains the 

embedded BSSLAP U-TDOA Request message. The U-TDOA Request message contains the required number 
of received upHnk RLC/MAC blocks, repetitions of the RLC/MAC Packet polHng request procedure or 
combination of both. The inclusion of this Polling Repetition information element in the U-TDOA Request 
message indicates that the location determination shall occur in the PS domain. 

2. The BSS sends a BSSMAP-LE Connection Oriented Information message to the SMLC that contains the embedded 
BSSLAP U-TDOA Response message. The U-TDOA Response message contains; the physical channel information 
(frequencies, time slot, TFI, TLLI, start time, etc.); the MS power; the cell identifier; and the Timing Advance. For MS 
without an existing uplink or downlink TBF the BSS establishes a downlink TBF, if one does not currently exist. The 
BSS monitors any uplink TBF until the requested number of RLC/MAC blocks has been received, executes the 
specified number of Packet polling procedures on the lowest numbered timeslot in the case of a multi-slot TBF or a 
combination of both as described in sub-clause 9.5.2.1. The BSS releases any downlink TBF established solely for U- 
TDOA location. 



9.5.2.4 



RLC/MAC Procedure affecting the PS U-TDOA TBF description 



The RLC/MAC procedures that effect the U-TDOA channel description are listed in Table 9.5.3. The 'Treatment' 
column lists the message to be sent by the BSS to the SMLC. The Reset message is defined in 3GPP TS 48.071 and 
shall contain the updated channel description. After sending the Reset message the BSS shall wait for an 
implementation dependent interval to allow reconfiguration of the LMUs, start the U-TDOA location process from the 
beginning and continue supervision of the location request. 

Table 9.5.3: RLC/IVIAC Procedures affecting the PS U-TDOA channel description 



RLC/MAC Procedure 


Treatment 


Comments 


Packet Timeslot Reconfigure 


Reset 




Packet Access Reject 


Reset 


Access retry cases 


Cell Reselection 


Reset 


MS originated (intra-BSS) 


Packet Cell Change Order 


Reset 


Network originated (intra-BSS) 



If the BSS receives the BSSLAP U-TDOA Request message during one of the identified RLC/MAC procedures in 
Table 9.5.3, it will complete the ongoing RLC/MAC procedure and then respond with the BSSLAP U-TDOA Response 
message. The Reset message must be sent after completion of the listed RLC/MAC procedure if that procedure must be 
executed during an ongoing U-TDOA location event. 



9.5.2.5 



Error Handling during PS U-TDOA Positioning Procedure 



In Table 9.5.4, all identified RLC/MAC procedures are listed that result in the BSSLAP Abort message to be sent from 
the BSS to the SMLC. The Abort message is only sent if the U-TDOA location determination is not complete. The BSS 
considers the location determinations complete if; it receives a BSSAP-LE Perform Location response message; or it 
receives a valid BSSLAP message for a new positioning method. 
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Table 9.5.4: RLC/MAC Procedures resulting in Error Handling 



RLC/MAC Procedure 


Treatment 


Comments 


Cell Reselection 


Abort 


MS originated (inter-BSS) 


Packet Cell Change Order 


Abort 


Network originated (inter-BSS) 


Packet Pause 


Abort 




Packet Access Reject 


Abort 


Cases without access retry indication 



If the ESS is unable to perform the U-TDOA positioning for other reasons than those related to the items listed in Table 
9.5.3 and Table 9.5.4, it will respond to the BSSLAP U-TDOA Request message with the BSSLAP Reject message. 



1 Information storage 



This clause describes information storage structures that are mandatory (M), conditional (C) or optional (O) for LCS in 
GERAN, and the recovery and restoration procedures needed to maintain service if inconsistencies in databases occur 
and for lost or invalid database information. 

10.1 SMLC 

Common Data 

Table 2 holds permanent BTS data: 

Table 2: Permanent SIVILC Data for a BTS 



Permanent BTS Data Item 


Status 


Description 


BTS position 


M 


BTS position (latitude/longitude) of the Serving BTS 


CGI 


M 


Cell global identity. 


BSIC 


M 


Base station identity code. 


BCCH 


M 


Frequency of the broadcast carrier. 



The SMLC holds data for its associated LMUs. The main key to LMU data in the SMLC is the IMSI for a Type A LMU 
and a cell site identifier for a Type B LMU. LMU data provides the location capabilities of the LMU (e.g. which 
location and assistance measurements are supported). The following permanent data shall be administered for any 
LMU. 
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Table 3: Permanent SMLC Data for an LMU 



Permanent LMU Data Item 


Status 


Description 


Type of LMU 


M 


Indicates if LIVIU is Type A or Type B 


IMSI 


C 


Main key to data for a Type A LMU. Not applicable to a Type B LMU 


LAC + CI 


C 


Cell site identifier to address a Type B LMU. Not applicable to a Type A 
LMU. 


Signaling Access 


M 


Information regarding signalling access to the LMU including the 
following: 

- address of default serving BSC 

- SS7 link set to serving BSC (or to an intermediate STP) 


Serving Cell 


M 


Identity of the cell in which the LMU is physically located 


Geographic location 


C 


Latitude/longitude coordinates 

Storage of coordinates is mandatory for E-OTD if an LMU is not co- 
located with a BTS 


Position measurement 
functions 





List of supported position measurements 

For each type of position measurement, a list of associated capabilities - 

details are outside the scope of the present document 


Assistance measurement 
functions 





List of supported assistance measurements 

For each type of assistance measurement, a list of associated capabilities 

- details are outside the scope of the present document 


Diagnostic functions 





List of supported diagnostic functions - details are outside the scope of 
the present document 



The SMLC also holds the following temporary data for each LMU for which there has been any previous signalling 
interaction. 

Table 4: Temporary SMLC Data for an LMU 



Temporary LMU Data Item 


Status 


Description 


Position Measurements 


o 


Ongoing and scheduled position measurements ordered in the 
LMU by the SMLC - details are outside the scope of the 
present document 


Assistance Measurements 


o 


Ongoing and scheduled assistance measurements ordered by 
the SMLC - details are outside the scope of the present 
document 


O&M Activities 


o 


Ongoing and scheduled O&M activities ordered in the LMU by 
the SMLC - details are outside the scope of the present 
document 



An LMU contains no mandatory data regarding its associated SMLC. An LMU shall contain permanent data regarding 
its measurement and O&M capabilities and may contain pre-administered data regarding location assistance 
measurements and O&M activities that the LMU is to perform without the need for any command from the SMLC. The 
content of such location measurement and O&M related data is outside the scope of the present document. 

10.2 Recovery and Restoration Procedures 

The LCS recovery and restoration procedures allow temporary data to be recovered or re-initialized following loss or 
corruption of data, such that normal LCS service is rapidly restored and inconsistency between the data held by 
different LCS network elements is removed. For a full description, refer to 3GPP TS 23.007 [4]. 
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